![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
|
Server rebooted occasionally after power failure. And I have stale postmaster.pid file, so postmaster didn't start with error bill postgres[600]: [1-1] FATAL: file "postmaster.pid" already exists |
#2
| |||
| |||
|
|
We've fixed this in recent releases by having the postmaster also check for a match to its parent process ID (getppid). The care in the start script comes because this only works for one level up. Therefore, you can't "su -c pg_ctl start ..." because that would create three levels of postgres-owned processes (shell, pg_ctl, postmaster) and if the PID count is off by 2 instead of 1 then we still lose. You have to invoke the postmaster directly, "su -c postmaster ...". (Hm, actually it might work to do "su -c 'exec pg_ctl ...'" ... I have not tried that.) |
#3
| |||
| |||
|
|
Except that the shell that's running su would be root, not pgsql, at least in the case of FreeBSD. The guts of the current port's rc.d file are: su -l ${postgresql_user} -c "exec ${command} ${command_args} ${rc_arg}" |
#4
| |||
| |||
|
|
"Jim C. Nasby" <jnasby (AT) pervasive (DOT) com> writes: Except that the shell that's running su would be root, not pgsql, at least in the case of FreeBSD. The guts of the current port's rc.d file are: su -l ${postgresql_user} -c "exec ${command} ${command_args} ${rc_arg}" Yeah, but what's the ${command} ? If it's pg_ctl then all he's missing is the recent change to check getppid. If it's execing postmaster directly then maybe we need another theory. |
#5
| |||
| |||
|
|
Yeah, but what's the ${command} ? If it's pg_ctl then all he's missing is the recent change to check getppid. If it's execing postmaster directly then maybe we need another theory. It's pg_ctl.... command=${prefix}/bin/pg_ctl |
![]() |
| Thread Tools | |
| Display Modes | |
| |