On Sat, May 28, 2011 at 20:06, Christian Parpart <tra...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel