Bug 103767 - postmaster log file is always empty
postmaster log file is always empty
Product: Red Hat Linux
Classification: Retired
Component: postgresql (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
: 122447 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-09-04 15:44 EDT by Patrick J. LoPresti
Modified: 2013-07-02 22:59 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-23 23:31:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Patrick J. LoPresti 2003-09-04 15:44:14 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):

How reproducible:

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
Actual results:
No log messages

Expected results:
Log messages

Additional info:
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.
Comment 1 David Jee 2003-09-04 16:00:35 EDT
The init script is currently being overhauled.  I will make sure that
your suggestion is taken into consideration.
Comment 3 Fernando Nasser 2004-01-08 15:35:16 EST
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).
Comment 4 Tom Lane 2004-03-10 16:02:04 EST
"-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
Comment 5 Lamar Owen 2004-03-12 14:28:36 EST
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.
Comment 6 Fernando Nasser 2004-03-12 14:54:25 EST
Hi Lamar,

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.

Comment 7 Tom Lane 2004-05-05 22:45:02 EDT
*** Bug 122447 has been marked as a duplicate of this bug. ***
Comment 8 Tom Lane 2005-01-23 23:31:28 EST
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.

Note You need to log in before you can comment on or make changes to this bug.