Re: [Patch] Create a new session in postmaster by calling setsid() - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [Patch] Create a new session in postmaster by calling setsid()
Date
Msg-id fc327e80-d68b-e8ea-cdf4-df65b3d9abfa@iki.fi
Whole thread Raw
In response to Re: [Patch] Create a new session in postmaster by calling setsid()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [Patch] Create a new session in postmaster by calling setsid()
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Prepare Transaction support for ON COMMIT DROP temporary tables
Next
From: Dimitri Fontaine
Date:
Subject: Re: Prepare Transaction support for ON COMMIT DROP temporary tables