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

Matt Hoosier matt.hoosier at gmail.com
Fri Apr 17 07:00:49 PDT 2015


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.

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.

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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150417/c109bd07/attachment.html>


More information about the systemd-devel mailing list