Quoting Marcus J. Ranum <mjrat_private>: > > >homebrew: cp logfile logfile.$TODAY && cp /dev/null logile > > It's probably better to use > touch logfile > instead of > cp /dev/null logfile > on the outside chance that something has actually been written to > the log file. Also, usually, this is done with the 'mv' command, which > is faster and less likely to result in more data piling up in the > old logfile. So what I'd suggest looks more like: > > mv logfile logfile.$TODAY && touch logfile > > mjr. (a bit rusty with UNIX...) I'm sure almost everyone knows this but hey... Both methods are acceptable (though I found a box where /dev/null had its permission set randomly to 000 and the logfiles overflowed because of just this). Almost all programs that write to logfiles keep the file-descriptors open for their logfiles. The file-descriptor refers to a particular inode on a filesystem, not to a file-name, /per se/. So moving a file within a filesystem will mean that syslog continues to write to this newly-renamed file. If the file is removed (rm or mv between filesystems), the kernel is merely unlinking it from a directory, and since there is still at least one file-descriptor referring to it, the file itself can still be written to. Typically you get a syslog daemon to close its file-descriptors by sending a HUP to it, although this is mere convention. So the sequence of events to analyse a logfile and rotate one goes: $ mv logfile logfile.trans # syslogd still writing to it $ kill -HUP `cat /var/run/syslogd.pid` # syslogd will open logfile $ logcheck-script < logfile.trans -- Andrew Stribblehill Systems programmer, IT Service, University of Durham, England --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Fri Sep 14 2001 - 06:26:37 PDT