<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>  #foo.service</div><div>  [Unit]</div><div>  Description=Proxy unit file for foo run prior to systemd</div><div>  ...</div><div><br></div><div>  [Service]</div><div>  Type=forking</div><div>  ExecStart=/bin/true</div><div>  PIDFile=/var/run/my-hand-forked-process-pidfile.txt</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div><br></div></div>