Re: [Patch] Create a new session in postmaster by calling setsid()

On 30/09/2018 15:47, Michael Paquier wrote:
> On Thu, Sep 13, 2018 at 12:24:38PM -0700, Andres Freund wrote:
>> On 2018-09-13 15:27:58 +0800, Paul Guo wrote:
>>> From the respective of users instead of developers, I think for such
>>> important
>>> service, tty should be dissociated, i.e. postmaster should be daemonized by
>>> default (and even should have default log filename?) or be setsid()-ed at
>>> least.
>>
>> I don't think it'd be good to switch to postgres daemonizing itself. If
>> we were starting fresh, maybe, but there's plenty people invoking
>> postgres from scripts etc. And tools like systemd don't actually want
>> daemons to fork away, so there's no clear need from that side either.
>
> It seems to me that the thread is pointing out that we would not want
> the postmaster to daemonize itself, but that something in pg_ctl could
> be introduced, potentially optional. I am marking this patch as
> returned with feedback.

Hmm. So, the requirements are:

1. When launched from pg_ctl, postmaster should become leader of a new
session and process group. To address Paul's original scenario.

2. If "postmaster" is launched stand-alone from terminal or a script, it
should stay in foreground, in the parent session, so that it can be
killed with Ctrl-C.

3. Hitting Ctrl-C while "pg_ctl start -w" is waiting for postmaster to
start up, should "abort" and kill postmaster.

We talked about adding a flag to postmaster, to tell it to call
setsid(). But I'm not sure what would be the appropriate time to do it.
If it's done early during postmaster startup, then we still wouldn't
have solved 3. Hitting Ctrl-C on pg_ctl, while the server is still in
recovery, would not kill the server. We could do it after recovery has
finished, but if we have already launched auxiliar processes, I think
they would stay in the old process group and session. So I don't think
that works.

Another idea would be to call setsid() in pg_ctl, after forking
postmaster, like in Paul's original patch. That solves 1. and 2. To
still do 3., add a signal handler for SIGINT in pg_ctl, which forwards
the SIGINT to the postmaster process. Thoughts on that?

- Heikki