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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel