Description of problem: After system crashes, the postgresql service won't start, because of the PID file /var/lib/pgsql/data/postmaster.pid still exists after rebooting. Unfortunately, the PID was already valid again after reboot (process httpd..). BTW: It's not good to pipe all the postmaster start output to /dev/null, including the error log. Better will be to put this messages to boot.log. Version-Release number of selected component (if applicable): 7.2.1-5 How reproducible: Didn't try Steps to Reproduce: 1. Hard system reset 2. PID in postgresql PID file was owned after reboot by another process 3. Try to start postgresql Actual Results: Service won't start Expected Results: Initscript detects stale PID file or it will be deleted on booting. Additional info:
Any possibility of removing pid files in the initscripts, Bill?
We remove ones in standard directories (i.e., /var/run). Anything in non-standard directories probably needs to be handled by the app's init script.
The pid file in question is /var/run/postmaster.pid, so it should work then... recent addition?
The pid file referenced in the bug is /var/lib/pgsql/data/postmaster.pid
Doh. Yes, there are two. One by the initscript, one for the database. I'll just forceably remove the latter.
This is being addressed in some reworking of the init script. Reassigning.
I've finally found a hack that solves this problem without the risks involved in forcibly deleting the lock file. It's fixed for FC3 and RHEL3 U4. See bug #134090.