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 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.
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 program.
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.
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
*** 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.