[systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Matt Hoosier]

On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering <lennart at poettering.net
> wrote:

> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoosier at gmail.com) wrote:
>
> > Hi,
> >
> > I'm writing to see whether there's a "best" way to allow systemd to
> inherit
> > ownership of a process forked from a hand-crafted /sbin/init process
> before
> > that hand-crafted process turns over the keys to systemd by doing
> > exec("/lib/systemd/systemd") over the top of itself and allowing it to
> take
> > over as PID 1.
>
> We support this only really for "kernel-like" processes that are
> started from the initrd, and basically run as long as the system is up
> without every being restarted in between, thus effectively appearing
> much like a kernel process and nothing systemd should
> manage. Processes like this should be marked with argv[0][0] = '@',
> see for details:
>
> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
>
> > I know that sounds like an odd thing to ask about. The use-case has to do
> > with being able to start some work extremely early during boot of
> embedded
> > systems to achieve performance goals. I don't wish to subvert systemd,
> and
> > in fact would love for systemd to be able to monitor the process, stop
> it,
> > restart according to the normal [Service] configuration in a unit file
> > describing the process.
>
> Hmm, are you sure that invoking the binary from systemd as first
> service is really that much slower than starting systemd only afterwards?
>

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.

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:

    [Unit]
    DefaultDependencies=no
    Before=very-first-normal-systemd-unit.service

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.


>
> > I can achieve a poor man's version of this right now by telling my
> > hand-spawned process to write out a pid file, and then supplying a unit
> > file that looks something like:
> >
> >   #foo.service
> >   [Unit]
> >   Description=Proxy unit file for foo run prior to systemd
> >   ...
> >
> >   [Service]
> >   Type=forking
> >   ExecStart=/bin/true
> >   PIDFile=/var/run/my-hand-forked-process-pidfile.txt
>
> urks, but yeah, this should work, however, this will not move the
> process into the service's cgroup. For that you can probably script
> something easily that echoes the PID manually into the cgroups dir of
> the service (which you can reference via %c).
>
> > This is at least enough to get my process into the overall dependency
> graph
> > and to allow other units to depend on the process nominally described by
> > foo.service. But any kind of use of the 'Restart' option is out of the
> > question using this approach. Similarly, 'systemctl start foo.service'
> > wouldn't be able to really start the service explicitly.
> >
> > Is there a (sneaky?) way to inform systemd that a daemon described
> property
> > in a service file, has already been launched and that systemd should
> simply
> > adopt the running instance?
>
> Not really. Maybe you can make the start routine of your daemon smart
> enough to check if the daemon is already up. If so, you move that
> process to the cgroup the routine is started in. If not you fork off
> the real daemon. That way, you can start the daemon before systemd,
> then systemd will start it again, but instead of forking off a new
> instance it would just adopt the existing instance by systemd. When
> the daemon is the restarted through systemd then it will terminate the
> daemon cleanly and the new forked of process will be a regular again,
> if you follow what I mean.
>

Fair enough. That approach had occurred to me also.


>
> But this is all ugly, this is really nothing we want to support
> officially I am sure...
>

Understood.


>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150417/7941e8ac/attachment.html>