Bug 103767 - postmaster log file is always empty
Summary: postmaster log file is always empty
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: postgresql
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom Lane
QA Contact:
URL:
Whiteboard:
: 122447 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-09-04 19:44 UTC by Patrick J. LoPresti
Modified: 2013-07-03 02:59 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-01-24 04:31:28 UTC
Embargoed:


Attachments (Terms of Use)

Description Patrick J. LoPresti 2003-09-04 19:44:14 UTC
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
there.

Version-Release number of selected component (if applicable):


How reproducible:
100%

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 20:00:35 UTC
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 20:35:16 UTC
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 21:02:04 UTC
"-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
program.

Comment 5 Lamar Owen 2004-03-12 19:28:36 UTC
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 19:54:25 UTC
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.

Regards,
Fernando

Comment 7 Tom Lane 2004-05-06 02:45:02 UTC
*** Bug 122447 has been marked as a duplicate of this bug. ***

Comment 8 Tom Lane 2005-01-24 04:31:28 UTC
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.