Red Hat Bugzilla – Bug 103767
postmaster log file is always empty
Last modified: 2013-07-02 22:59:46 EDT
Description of problem:
The postgresql RPM creates the /var/log/pgsql file and gives ownership of it to
postgres.postgres, but the server (postmaster process) never writes any output
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start server
2. Do something which should generate a log message
3. Observe that /var/log/pgsql is still zero bytes
No log messages
I noticed this because the server returned an error (via a PHP page) which said
"consult PostgreSQL postmaster log for more information".
I believe this can be fixed by adding "-l /var/log/pgsql" to the invocation of
pg_ctl in /etc/init.d/postgresql.
The init script is currently being overhauled. I will make sure that
your suggestion is taken into consideration.
This is a init script problem. I still plan to do it as I need it for
the ControlCenter (it has to install the script for each new database
Service that is created and it must log and use the settings as expected).
"-l /var/log/pgsql" is not a good solution because the log file would
grow indefinitely --- the postmaster has no provision for rotating the
file. We intend eventually to put a log-rotation program into the
Postgres distribution. In the meantime, you could either modify
postgresql.conf to use syslog logging, or change the init script to
send the postmaster's stdout/stderr to the Apache log rotation
The original intent that I had (a log time ago) for /var/log/pgsql was
to receive syslog output and to be rotated using the standard
logrotate functionality included in RHL. Ancient copies of the RPM
can be perused to see that I had a logrotate script already set up,
just had not done the code to have syslog send PostgreSQL logging
information to /var/log/pgsql. That involved editing /etc/syslog.conf
on the fly, which was something I ended up not doing. I should have
removed /var/log/pgsql at the same time I removed the logrotate
script, but I did not do so.
What I wanted to do was to automatically set up syslog to put
postmaster and backend messages into /var/log/pgsql and have it
rotated as needed. Then postgresql.conf would be patched to enable
syslog with medium verbosity and logging with a 'reasonable' set of
defaults so that it wouldn't overwhelm with its verbosity.
All this works and our Control Center (now an open source project)
lets you set up all log parameters inclusive log rotation for any of
the several database servers you may be running on your system (each
one can have different settings). It also supports log using Syslog.
My new init script (end of this month) honors the logging setting and
send it to the right place.
The only problem is that the log rotation requires a command to cause
the application which is logging to close and open again the file that
is being written so that it gets the new one and do not keep writing
to the old one.
Normally this is just a signal and the command is 'kill -USR2
myserver' but the postmaster cannot do that because it has no way to
tell all the other postgres processes at the same time.
The solution proposed by Tom Lane is to pass the postgres output
through a logrotate pipe program that can handle the conventional
SIGUSR2 and close+open the log file, making the change of files effective.
*** Bug 122447 has been marked as a duplicate of this bug. ***
PostgreSQL 8.0 finally has an internal log rotator, and I've set up the 8.0 RPMs to use it by
default. This fix will appear in FC4, RHEL5 and later.