Re: Ctrl+C from sh can shut down daemonized PostgreSQL cluster

On Mon, Feb 17, 2014 at 8:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> It certainly might be --- I have no idea. What surprised me is that we
>> are relying solely on system() to block signals to pg_ctl-spawned
>> servers. The question is whether that is sufficient and whether we
>> should be doing more. I don't think we have to make adjustments just
>> for Solaris 9.
>
> We aren't relying on system(); it does no such thing, according to the
> POSIX spec. If it did, pg_ctl would be unable to print any errors to the
> terminal, because dissociating from the foreground process group generally
> also disables your ability to print on the terminal.
>
> I poked around in the POSIX spec a bit, and if I'm reading it correctly,
> the only thing that typically results in the postmaster becoming
> dissociated from the terminal is use of "&" to launch it. In a shell
> with job control, that should result in the process being put into a
> "background" process group that won't receive terminal signals nor be
> permitted to do I/O to it. This is distinct from dissociating altogether
> because you can use "fg" to return the process to foreground; if we did a
> setsid() we'd lose that option, if I'm reading the standards correctly.
> So I'm loath to see the postmaster doing setsid() for itself.
>
> POSIX also mandates that interactive shells have job control enabled by
> default.
>
> However ... the "&" isn't issued in the user's interactive shell. It's
> seen by the shell launched by pg_ctl's system() call. So it appears to
> be standards-conforming if that shell does nothing to move the launched
> postmaster into the background.
>
> The POSIX spec describes a shell switch -m that forces subprocesses
> to be launched in their own process groups. So maybe what we ought
> to do is teach pg_ctl to do something like
>
> system("set -m; postgres ...");
>
> Dunno if this is really portable, though it ought to be.
>
> Alternatively, we could do what the comments in pg_ctl have long thought
> desirable, namely get rid of use of system() in favor of fork()/exec().
> With that, pg_ctl could do a setsid() inside the child process.

I like this last approach. It seems to me that the problem with
system() is that it's relying on the user's shell to have sane
behavior. And while that obviously will work fine in a whole lot of
cases, I don't see why we should rely on it. I don't think "your
shell must support -m with POSIX-like semantics" is really a
requirement we want to impose on PostgreSQL users. The shell can't
make any system calls that we don't have access to ourselves, and
setsid() seems like the right one to use. Maybe it's begging for
trouble to change anything here at all, but I think if we are going to
make a change it ought to be in the direction of making us less
dependent on the vagaries of the user's shell, not more.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company