Date: Wed, 2 Jul 2003 12:01:58 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Jim Xochellis <dxoch@escape.gr> Cc: freebsd-questions@freebsd.org Subject: Re: About newsyslog behavior Message-ID: <20030702110158.GA39403@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <C02C7B00-AC6C-11D7-A8D3-003065C4E486@escape.gr> References: <C02C7B00-AC6C-11D7-A8D3-003065C4E486@escape.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
--45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 02, 2003 at 12:08:31PM +0300, Jim Xochellis wrote: > I am using the newsyslog utility to turn over my log files=20 > automatically. I have noticed that some processes have problem to=20 > continue using their log file after newsyslog has turned it over and=20 > need to receive the SINGHUP signal to re-start logging correctly.=20 > However sending SINGHUP has uncomfortable consequences in some cases=20 > (for instance when sending signal to netatalk, or other file servers=20 > perhaps). That's 'SIGHUP', although I do like the idea of the kernel singing to it's processes to keep them in line... The use of the SIGHUP signal to tell a long-running process to reconfigure itself, reopen all of it's file descriptors etc. is a very useful convention, but unfortunately it is only a convention -- as you've found out many processes don't follow it. > I suspected that some processes are confused because a *new* log file=20 > is created and these processes are making the assumption that their log= =20 > file will be always the same and perhaps they open it once and then=20 > work with the FILE pointer. (just a simple theory that explains some=20 > facts) I have confirmed that newsyslog actually creates a new log file=20 > (instead of copying it and then disposing its contents) by reading the=20 > source of the newsyslog.c file and particularly the dotrim() function.=20 > I have also tested that changing the contents of the log files by hand=20 > does not affect the logging of most processes (surely not the logging=20 > of netatalk). Yes, this is certainly true. You can confirm that the process in question is holding an open file decriptor on the log file by use of the fstat(1) command. Now, it's entirely possible to cycle log files by essentially: # cp log log.old # cat /dev/null > log (instead of what newsyslog does which is effectively: # mv log log.old # touch log ) but this still has problems. Somehow, you'ld need to tell the process with the open file descriptor that the underlying file had shrunk in size, and that it should do an fseek(stream, 0, SEEK_END) --- other wise, it will write any new data at the same file offset as the former end-of-file, leading to all sorts of weirdnesses. > Having the above in mind, isn't it worthwhile to add an option in=20 > newsyslog in order to avoid the creation of a new log file when it is=20 > inconvenient? > Isn't it feasible to dispose the contents of the old log file instead=20 > of creating a new one? > Anything that I am missing here? (giving the fact that I am not a unix=20 > guru, only a C programmer) One thing that might be of use if you're stuck with a program that won't play ball with newsyslog is to use something like cronolog(1) which is in ports as sysutils/cronolog --- see http://www.ford-mason.co.uk/resources/cronolog/ However, this requires that your program can write it's log output to a pipe rather than directly to a file. cronolog will manage switching to a new log file according to the time and date. Or you could code up a very simple equivalent that reads log messages from it's stdin and writes to the named log file, but that can handle a SIGHUP telling it to reopen the log file. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/ArumdtESqEQa7a0RAsodAKCAbUn5wrOtkxt8FUI8pGcV3i14FACfdE8a R6hvx1ipIVUyJ2pdH9sspr0= =HMH0 -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030702110158.GA39403>