NEVERMIND!

Ronald F. Guilmette rfg at tristatelogic.com
Tue May 27 02:46:16 UTC 2014


In message <20140527004708.U5669 at sola.nimnet.asn.au>, 
Ian Smith <smithi at 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.)


More information about the freebsd-security mailing list