Re: Rotating Log Files

Nevermind shorter/quicker, this will not work properly for any processes that keep an open file descriptor to their log file (i.e. almost every daemon process), because the fd will still point at the original inode and therefore keep logging to the now rotated file. For most daemons you need to send a SIGHUP to the parent process to reinitialise the logging. Take a look at the logrotate documentation and code for more details on this. That does not invalidate your code (it obviously still works for other processes), just thought I'd mention it.

A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox

Comment on Re: Rotating Log Files Download Code

Replies are listed 'Best First'.
Re^2: Rotating Log Files by aukjan (Friar) on Dec 28, 2005 at 12:20 UTC
That is correct.. I should have been more clear in my description.. This is actually more a snip for keeping a history of files instead of a history of logfiles... (I use it for rotating intermediate files used in NIS edited by many people using a 'special' script). Go Fish!	[reply]
Re^3: Rotating Log Files by tirwhan (Abbot) on Dec 28, 2005 at 12:41 UTC
Aah, I see. Well, while I'm giving unbidden advice ;-), I've found that in situations such as you describe it is beneficial to use an SCM software such as subversion. This makes it easy for many people to collaborate without one accidentally overwriting someone else's changes and gives you a nice history of who changed what when. Also, channeling the update through a repository action gives you another hook to add custom behaviour. Just a thought. A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox	[reply] [d/l]
Re^4: Rotating Log Files by aukjan (Friar) on Dec 28, 2005 at 13:54 UTC
Actually this script used to use RCS for locking/logging, but we found out it was giving more problems than benefits... So now we're changing it to something simpler (read: not depending too much on other software), including our own type of (more descriptive) locking... We now keep a couple of versions of the file, which makes restoring problems quicker in our environment. But thanks for the advice! Go Fish!	[reply]