Date: Mon, 26 May 2014 19:46:14 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: NEVERMIND! Message-ID: <9187.1401158774@server1.tristatelogic.com> In-Reply-To: <20140527004708.U5669@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9187.1401158774>