Log Rotation

[Scott W]

Gerard Samuel wrote:

> On Sunday 28 December 2003 12:36 pm, Lowell Gilbert wrote:
> 
>>Gerard Samuel <fbsd-questions at trini0.org> writes:
>>
>>>In particular, Im looking to see if there is a "FreeBSD" way in
>>>rotating PostgreSQL logs.
>>>Any advise would be appreciated.
>>
>>newsyslog(8) is part of the base system...
> 
> 
> Yes, Im familiar with newsyslog, but Im not sure how it will play with 
> rotating PostgreSQL's log file, as PostgreSQL seems to need some extra TLC 
> when rotating the log while PostgreSQL is running.
> http://www.postgresql.org/docs/7.3/interactive/logfile-maintenance.html
> Ill have to let that sink in the brain, before I try messing with it.
> 
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 

Just a guess here, but what the problem likely is is that Postgres keeps 
a file descriptor open to it's logfile, which means that 'simple' log 
rotation, eg just moving the original logfile to a backup name or 
gzipped file will break the logging as pg won't have a valid file 
descriptor any more.  This one's bit a project I worked on forever ago 
(on a production system! :-( ) running Solaris and Sybase...

The easy solution is to see if any of the log rotation scripts have the 
'right' behavior...if not, you can write your own script to do it, test 
it by rotating the logs and then intentionally doing something to 
produce log output (depending on your log level)...if you get the log 
output, everything's happy.  What it should be doing is this (and a side 
effect is you shouldn't run into log problems on other apps either):
1.  Copy the log file locally, using whatever naming convention you 
want, eg logname.(massaged date/time stamp like $(date | cut -f' '))
2.  Truncate the existing log via cat /dev/null > original logfile . 
This allows the logging progam to continue to log without an invalid fd..
3.  gzip or move the copied logfile to wherever, gzip it etc..

This is a simple solution, and has the potential to lose a few log 
entries due to the time from the completion of the original log copy 
until the original log file truncation is completed, but should be fine 
for home, non critical or low usage (meaning not logging 1000 
messages/minute) log files....there's probably a better way to do this, 
probably logging via a pipe, but I don't know the specifics offhand...

HTH,

Scott