From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 Description of problem: What happens: If postgresql is installed, started up successfully (to init the database), shut down, then configured with tcpip support and ssl support switched on, then started up again, the following message is logged: [root@chandler data]# service rhdb start Starting rhdb service: [FAILED] The first port of call is /var/log/messages, it contains this: May 4 11:38:17 chandler su(pam_unix)[23551]: session opened for user postgres by (uid=0) May 4 11:38:17 chandler su(pam_unix)[23551]: session closed for user postgres May 4 11:38:18 chandler rhdb: Starting rhdb service: failed Nothing helpful there. The log file /var/log/pgsql remains a zero length file. The log file /var/log/secure shows this: May 4 11:38:17 chandler su(pam_unix)[23551]: session opened for user postgres by (uid=0) May 4 11:38:17 chandler su(pam_unix)[23551]: session closed for user postgres In short: A failure to start has occurred, and the reason for the failure is not logged anywhere. What should happen: Logging should be correctly configured out the box, so that startup failures can be debugged without significant time wastage, as is the case now. Note: this bug has NOTHING to do with the failure to start, which I fully understand is a topic for online forums or external help. The bug is the lack of LOGGING in postgresql which is a bug in itself, and should be fixed. Just in case there was any doubt. Version-Release number of selected component (if applicable): rh-postgresql-7.3.4-9 How reproducible: Always Steps to Reproduce: xxx Additional info:
Yeah, the init script sends the postmaster's stderr to /dev/null, which is not real helpful. The best short-term fix is to configure postgres to log to syslog instead of stderr (see postgresql.conf). See also discussion at the linked-to bug. *** This bug has been marked as a duplicate of 103767 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.