postmaster -S will not print an error if pid file exists
If a second postmaster is started on a data directory and the second one
uses the -S option it will not print a message but simply exit and not
start a background process. The exit status is 0.
This seems to have gotten lost in the changes postmaster.c rev. 1.195,
global lock file changes by tgl.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
If a second postmaster is started on a data directory and the second one
uses the -S option it will not print a message but simply exit and not
start a background process. The exit status is 0.
Since the whole point of -S is to throw away stdout/stderr, I hardly
see how you can complain about the fact that the error message went
to /dev/null. I agree that zero exit status is not good, however;
will see if I can fix that.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
If a second postmaster is started on a data directory and the second one
uses the -S option it will not print a message but simply exit and not
start a background process. The exit status is 0.
On closer inspection, it's clear that the postmaster *does* exit with
status 1 after failing to lock the lockfile. However, since it's
already forked and detached from the terminal, you can't see the status
1; the parent process exited with status 0. Postponing the fork till
after we grab the lockfile will not do, because then the lockfile will
contain the wrong postmaster PID.
I have stated before that I consider -S evil. Don't complain too hard
about its behavior, or I'll fix it by ripping it out, lock stock and
barrel ;-)
regards, tom lane