[systemd-devel] Revisiting the "ExecRestart" issue

[Lennart Poettering]

On Tue, 01.04.14 01:55, Brandon Black (blblack at gmail.com) wrote:

> On Fri, Mar 28, 2014 at 12:12 PM, Brandon Black <blblack at gmail.com> wrote:
> >
> >   Given where things are at today, as best I can tell my best bet is to go
> > down that sort of road, though, and try to clone over the cgroups
> > memberships manually somehow during an ExecReload= command for this restart
> > (even though it really is a restart), and leaving true reloads (SIGHUP to a
> > running daemon) to be done from outside systemd.
> >
> 
> I've done some experimenting this evening (on a Fedora 20 system w/
> systemd-208),
> playing with methods of MAINPID notification and how to coerce
> ExecReloadinto letting me do an overlapped restart.  The result is
> that I can make it
> work, but it's hacky.  The main thing that bothers me about it is that the
> mechanisms probably aren't officially supported interfaces and my methods
> will randomly fail on a future version of systemd (or a
> differently-configured distro).

You should be able to either inform systemd of new new PID by sending
MAINPID, or simply write a new PID file out, systemd should read it
again, if you configure it with PIDFile.

> To recap my results: there were primarily two things in the way of naively
> using ExecReload to trigger gdnsd's overlapped restart:
> 
> 1) gdnsd wants to use sd_notifyf() to indicate the MAINPID switch in the
> new daemon, which is a descendant of the ExecReload process.  The
> ExecReloadprocess doesn't get a copy of $NOTIFY_SOCKET even with
> NotifyAccess=all.  So I hacked around that by having the daemon set
> $NOTIFY_SOCKET for itself, to the value "@/org/freedesktop/systemd1/notify",
> which seems semi-standard for the moment.
> 
> 2) ExecReload control processes can't become the MAINPID even after
> notification because they're not in the correct cgroup (or subgroup, or
> whatever it is that's special about most control procs), unlike
> Start'scontrol process, which is in the right
> cgroup for its descendants to become MAINPID successfully.  This was hacked
> around by grabbing the basic unit name from sd_pid_get_unit() (let's call
> the result "$U") and then writing our pid to "/sys/fs/cgroup/systemd
> /system.slice/$U/cgroup.procs" from the new daemon before it drops root
> privs and later notifies about the MAINPID switch.

Hmm, yeah, the new process really needs to be forked off the original
main process. Control processes really can't become the main process I
fear...


Lennart

-- 
Lennart Poettering, Red Hat