On Mon, 26 May 2014 19:46:14 -0700, Ronald F. Guilmette wrote: > 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. I was more thinking that syslogd might use its own criteria, based on preservation of functionality in the face of DoS (or pilot error) in regard to its diskspace requirements. I used delta filesize (rate of file growth) in a script against a certain DNS mini-DoS some years ago and found it effective for both reporting and blacklisting offenders. And don't forget remote logging, where syslogd has no clue re filesize. > >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). Except that newsyslog isn't a daemon; it's a userland program, usually invoked hourly by cron, which usually itself sends a HUP signal to the daemon associated with a rotated log. It already has ability to work on single file/s and to avoid signalling its caller, and in fact may need no modification at all .. but I've never played with its many options. > 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.) Which is more or less what des@ suggested, rather to my surprise. To me it doesn't smell quite right, unix-philosophically, merging two distinct processes that each perform related but really very separate functions, near doubling the size and complicating the functionality of the daemon. But I'm no more likely than you are to be able to do anything about it, so I'll leave it there. cheers, Ian _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"