About newsyslog behavior

[Matthew Seaman]

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 
> automatically. I have noticed that some processes have problem to 
> continue using their log file after newsyslog has turned it over and 
> need to receive the SINGHUP signal to re-start logging correctly. 
> However sending SINGHUP  has uncomfortable consequences in some cases 
> (for instance when sending signal to netatalk, or other file servers 
> 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 
> is created and these processes are making the assumption that their log 
> file will be always the same and perhaps they open it once and then 
> work with the FILE pointer. (just a simple theory that explains some 
> facts) I have confirmed that newsyslog actually creates a new log file 
> (instead of copying it and then disposing its contents) by reading the 
> source of the newsyslog.c file and particularly the dotrim() function. 
> I have also tested that changing the contents of the log files by hand 
> does not affect the logging of most processes (surely not the logging 
> 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 
> newsyslog in order to avoid the creation of a new log file when it is 
> inconvenient?
> Isn't it feasible to dispose the contents of the old log file instead 
> of creating a new one?
> Anything that I am missing here? (giving the fact that I am not a unix 
> 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


-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20030702/53730ce5/attachment.bin