On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering <lenn...@poettering.net > wrote:
> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@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
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel