Red Hat Bugzilla – Bug 76503
SysV Init Scripts Not Reporting Error(s)
Last modified: 2013-07-02 22:59:45 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) Description of problem: Starting postgres with the following line below eats critical error information. We has a stale PID file and the error was not logged anywhere and the Starting Postgres: Failed message doesn't really tell you a lot. su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl -D $PGDATA - p /usr/bin/postmaster start > /dev/null 2>&1" < /dev/null Version-Release number of selected component (if applicable): At least since Redhat 7.2 How reproducible: Always Steps to Reproduce: 1. Create a PID File for Postgres 2. Start Postgres and it Fails to start with no further error message 3. Expected Results: The warning about the PID file and shared mem handle should have been displayed and not sent to /dev/null Additional info: Proposed fix would be a postgres-console.log in /var/log owned by postgres.postgres and change the init script to reflect it as such. su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl -D $PGDATA - p /usr/bin/postmaster start > /var/log/postgresql-console.log 2>&1" < /dev/null
Assigning to me.
Reassigning.
Eric, you are absolutely right -- we must save the log somewhere. The fix is not that simple because the PostgreSQL backend generates an excess of messages that would eat up your disk space. We need log rotation but the backend does not respond to any signal for that purpose. We will have to pipe the output through a program that does that. We are working on that and in the future you will be able to inspect the log. The situation with the stale pid file is another bug, already reported (#71295), as the script should be able to recover from that. It will be fixed in a future release.
Done finally in PostgreSQL 8.0.