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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 17, 2015 at 09:00:49AM -0500, Matt Hoosier 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.
> 
> 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?
See systemd.scope(5).

Zbyszek