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