Re: Postgres server output log

This is OK. The script isn't HUPping PostgreSQL, it is HUPping syslog.

I think configuring PostgreSQL to write to syslog is the correct way to go.

Once you decide to route the messages to syslogy you get everything that
syslog offers such as:
directing output to files, pipes or central log servers (in any combination)
selectively dropping or writing messages based on severity
many ready-made management tools like logrotate
many ready-made monitoring tools like swatch and logwatch

You can even choose alternate versions of the syslog daemon - I have one
server runing msyslogd (Modular Syslog Daemon) with the PostgreSQL module
installed so I can write syslog entries for a project directly into a
PostgreSQL database for retrieval or analysis.

So my advice is to complie/configure PostgreSQL to use syslog and use the
myriad of available syslog tools for management and analysis.

Cheers,
Steve



On Thursday 30 January 2003 4:40 am, Oliver Elphick wrote:
> On Thu, 2003-01-30 at 05:22, Rajesh Kumar Mallah. wrote:
> > This is someones' elses' posting that i have preserved
> > shud be useful.
>
> ...
>
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
> >
> > Well,
> > the most correct way to do a logrotate is ( Redhat ):
>
> ...
>
> > 2)  Put on the directory /etc/logrotate.d a file called
> > 'postgres' with the following lines:
> >
> > /var/log/postgresql.log {
> >     compress
> >     rotate 2
> >     size=10000k
> >     errors mendola@bigfoot.com
> >     create 0664 postgres postgres
> >     daily
> >     postrotate
> >              /usr/bin/killall -HUP syslogd
> >     endscript
> > }
>
> ...
>
> This won't work as it stands with PostgreSQL, because the hangup signal
> does not make the postmaster reopen the log file.  Instead of that
> postrotate section, you need to use logrotate's copytruncate option,
> which will copy the logfile to another file before zeroing the logfile.
>
> Depending on what is being logged, you may want to change the
> permissions to 660; there may be stuff in the logs that you don't want
> to reveal to the world.  (With copytruncate, I think the create option
> applies to the copy files rather than to the original logfile.)