In message <[email protected]>, Ian Smith <[email protected]> wrote: >... might syslog trigger adhoc rotations by >newsyslog - of a particular log, not all - after learning how to measure >'stress', perhaps by rates of delta filesize, diskspace consumption etc? (Not that anyone has any reason to care what _I_ think, but...) I must say that I like that idea. The specific thing (i.e. "measurment") that should trigger such an event/action seems altogether obvious. If syslogd is writing a file and it sees that the file in question has just exceeded its allowed maximum (according to /etc/newsyslog.conf) then it is clearly time to do something about it. >Then newsyslog would only need to learn how to be so invoked? How about "kill -HUP" ? That seems to be the pro-forma thing that pretty much everything else already uses as a way to tell any given daemon that it should wake up and smell the coffee (again). Of course, *if* one were in fact going to endow syslogd with all of the intelligence necessary to read, understand, check, and act on the various max filesize specifications contained within /etc/newsyslog.conf then that would certainly prompt the question: Why not just merge the two programs into one? (Obviously, that would eliminate the need for interprocess signaling of any kind.) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"