[systemd-devel] MAINPID changing

[Kay Sievers]

On Sat, May 28, 2011 at 20:06, Christian Parpart <trapni at gentoo.org> wrote:
> back in January there was a very big discussion on the whole MAINPID changing
> issue related to lighttpd. Well, now I've ran into this myself, and wonder
> whether systemd now supports changing the MAINPID.
>
> So what is the MAINPID in my case anyway?
>
> I start my (HTTP) server without backgrounding, in favor of systemd, and even
> use sd_notify()s to even inform PID 1 about more details.
> This process is the MAINPID for sure, while having CGIs forking off from time
> to time, that's all fine.
> But now, I've implemented graceful executable/config upgrade as follows:
>
> 1.) worker threads suspend
> 2.) all listeners stop accepting new connections
> 3.) all listeners get the FD_CLOEXEC flag enabled
> 4.) fork a new child
> 5.) exec new binary with new config
> 6.) watch for child exit (e.g. invalid config file / bad executable)
> 7.) clear FD_CLOEXEC from all listeners
> 6.) resume worker threads to continue processing currently active connections
>
> the child process then either exits, which will lead into the still-current
> MAINPID to accept() new connections, again, as if nothing happened.
>
> if the child process fully initialized, including inherited listener sockets,
> it sends a SIGQUIT to the parent (still the MAINPID) to *gracefully* shutdown,
> which might be this instant or take a few minutes, just until all current
> active requests have been fully processed.
> The still-MAINPID has exited now, and the child, our new MAINPID is now meant
> to be the MAINPID. but how to dell systemd about that?
>
> *** I'd whish some kind of sd_notify("MAINPID=%d", getpid()) here, if ***
>
> I hope I have described my situation in a depth, that everybody knows what
> exactly is going on during the MAINPID change, which is really needed, because
> I can't just reexec into the current process image, because I need the current
> connections to be completed cleanly.

You better re-exec _yourself_ and the pid stays the same, instead of
starting the service again a second time. All that only, if you really
want to play this game at all, which I'm not sure if it's too useful.

Kay