Thread: 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