<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 23, 2014 at 3:06 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">> To recap my results: there were primarily two things in the way of naively<br>
</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
> using ExecReload to trigger gdnsd's overlapped restart:<br>
><br>
> 1) gdnsd wants to use sd_notifyf() to indicate the MAINPID switch in the<br>
> new daemon, which is a descendant of the ExecReload process.  The<br>
</div>> ExecReloadprocess doesn't get a copy of $NOTIFY_SOCKET even with<br>
<div class="">> NotifyAccess=all.  So I hacked around that by having the daemon set<br>
> $NOTIFY_SOCKET for itself, to the value "@/org/freedesktop/systemd1/notify",<br>
> which seems semi-standard for the moment.<br>
><br>
> 2) ExecReload control processes can't become the MAINPID even after<br>
> notification because they're not in the correct cgroup (or subgroup, or<br>
> whatever it is that's special about most control procs), unlike<br>
</div>> Start'scontrol process, which is in the right<br>
<div class="">> cgroup for its descendants to become MAINPID successfully.  This was hacked<br>
> around by grabbing the basic unit name from sd_pid_get_unit() (let's call<br>
> the result "$U") and then writing our pid to "/sys/fs/cgroup/systemd<br>
> /system.slice/$U/cgroup.procs" from the new daemon before it drops root<br>
> privs and later notifies about the MAINPID switch.<br>
<br>
</div>Hmm, yeah, the new process really needs to be forked off the original<br>
main process.</blockquote><div><br></div><div>The problem here is that the daemon performs operations that require root privilege on startup, and then dumps its privileges for runtime, and thus its execve'd child won't have the root privs it would need to start everything over again.  In theory some of these privileged things, like listening sockets, could be handed to the exec child, but that assumes the configured set of listening sockets hasn't changed (which might be the reason for the restart).  Other things like mlockall() can't be handed off over fork/execve once privileges are gone.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Control processes really can't become the main process I<br>

fear...</blockquote><div><br></div><div>They can; I've already done it by writing to /sys as documented above, but that doesn't seem like a reliable API for doing so going forward on all platforms and in all situations.  What's the fundamental problem with officially letting a control process from ExecReload= become the main process via some reasonably-standard mechanism?  That's already what happens to the "control process" for ExecStart=.</div>
<div><br></div><div>I'd propose two changes (and work on the patches myself) that would make this case work for me reliably, if they're acceptable:</div><div><br></div><div>1) Can we get $NOTIFY_SOCKET set for control procs like ExecReload when NotifyAccess=all ?  That's what I initially thought that setting would do, but apparently it doesn't.  Or any other standard mechanism I could rely on so that I'm not hardcoding a fallback socket path.</div>
<div><br></div><div>2) Given the above, would it be reasonable that if a control process from a verb like ExecReload sent a MAINPID= message over the control socket, systemd would accept this as the new main pid *and* internally take care of promoting the specified PID to the proper cgroup?</div>
<div><br></div><div>-- Brandon</div></div></div></div>