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

[Lennart Poettering]

On Fri, 17.04.15 14:06, Matt Hoosier (matt.hoosier at gmail.com) wrote:

> 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.

This is not available, though often requested. But I doubt this can
ever work, since "running before 'everything'" or "running after
'everything'" is not particularly usefully defined as this all breaks
down as soon as you have two services that want to be run like this.

The right way is usually to simply add the right deps of the stuff you
really want to be run before.

That all said, I would be open to adding a "priority" concept to
units: if we are about to fork off a large number of processes at the
same time we do so sequentially but provide no control currently about
the order then. I'd be open making this configurable with a priority
values that can ensure we fork off some things before others when both
are runnable. This would not really fix your issue, sicne it wouldn't
really delay any other services, it would only configure the order of
the fork()s, but they'd still take place in a tight loop.

Lennart

-- 
Lennart Poettering, Red Hat