<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 17, 2015 at 12:22 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 17.04.15 09:00, Matt Hoosier (<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>) wrote:<br>
<br>
> Hi,<br>
><br>
> I'm writing to see whether there's a "best" way to allow systemd to inherit<br>
> ownership of a process forked from a hand-crafted /sbin/init process before<br>
> that hand-crafted process turns over the keys to systemd by doing<br>
> exec("/lib/systemd/systemd") over the top of itself and allowing it to take<br>
> over as PID 1.<br>
<br>
</span>We support this only really for "kernel-like" processes that are<br>
started from the initrd, and basically run as long as the system is up<br>
without every being restarted in between, thus effectively appearing<br>
much like a kernel process and nothing systemd should<br>
manage. Processes like this should be marked with argv[0][0] = '@',<br>
see for details:<br>
<br>
<a href="https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/" target="_blank">https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/</a><br>
<span class=""><br>
> I know that sounds like an odd thing to ask about. The use-case has to do<br>
> with being able to start some work extremely early during boot of embedded<br>
> systems to achieve performance goals. I don't wish to subvert systemd, and<br>
> in fact would love for systemd to be able to monitor the process, stop it,<br>
> restart according to the normal [Service] configuration in a unit file<br>
> describing the process.<br>
<br>
</span>Hmm, are you sure that invoking the binary from systemd as first<br>
service is really that much slower than starting systemd only afterwards?<br></blockquote><div><br></div><div>The bootcharting that I do seems to show that about 1.2 - 1.5 sec are spent internal to systemd before any external processes get run for the particular embedded CPU I'm using. That gap is a killer at the moment.</div><div><br></div><div>I'm sure this is quite the naive question, but: is there a simple option I can insert into my "super-important" first service that would cause all other units to be forestalled until my service reports that it's initialized? I.e., something like:</div><div><br></div><div>    [Unit]</div><div>    DefaultDependencies=no</div><div>    Before=very-first-normal-systemd-unit.service</div><div><br></div><div>I didn't have luck identifying such a very-first-normal-systemd-unit.service on my own, but I'm admittedly rather inexperienced poking around the internal default suite of units packaged with systemd.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I can achieve a poor man's version of this right now by telling my<br>
> hand-spawned process to write out a pid file, and then supplying a unit<br>
> file that looks something like:<br>
><br>
>   #foo.service<br>
>   [Unit]<br>
>   Description=Proxy unit file for foo run prior to systemd<br>
>   ...<br>
><br>
>   [Service]<br>
>   Type=forking<br>
>   ExecStart=/bin/true<br>
>   PIDFile=/var/run/my-hand-forked-process-pidfile.txt<br>
<br>
</span>urks, but yeah, this should work, however, this will not move the<br>
process into the service's cgroup. For that you can probably script<br>
something easily that echoes the PID manually into the cgroups dir of<br>
the service (which you can reference via %c).<br>
<span class=""><br>
> This is at least enough to get my process into the overall dependency graph<br>
> and to allow other units to depend on the process nominally described by<br>
> foo.service. But any kind of use of the 'Restart' option is out of the<br>
> question using this approach. Similarly, 'systemctl start foo.service'<br>
> wouldn't be able to really start the service explicitly.<br>
><br>
> Is there a (sneaky?) way to inform systemd that a daemon described property<br>
> in a service file, has already been launched and that systemd should simply<br>
> adopt the running instance?<br>
<br>
</span>Not really. Maybe you can make the start routine of your daemon smart<br>
enough to check if the daemon is already up. If so, you move that<br>
process to the cgroup the routine is started in. If not you fork off<br>
the real daemon. That way, you can start the daemon before systemd,<br>
then systemd will start it again, but instead of forking off a new<br>
instance it would just adopt the existing instance by systemd. When<br>
the daemon is the restarted through systemd then it will terminate the<br>
daemon cleanly and the new forked of process will be a regular again,<br>
if you follow what I mean.<br></blockquote><div><br></div><div>Fair enough. That approach had occurred to me also.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But this is all ugly, this is really nothing we want to support<br>
officially I am sure...<br></blockquote><div><br></div><div>Understood.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br></font></span></blockquote><div><br></div><div>-Matt </div></div><br></div></div>