看板 FB_security 關於我們 聯絡資訊
In message <20140527004708.U5669@sola.nimnet.asn.au>, Ian Smith <smithi@nimnet.asn.au> 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.) _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"