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

[Matt Hoosier]

On Mon, Apr 20, 2015 at 9:11 AM, Lennart Poettering <lennart at poettering.net>
wrote:

> 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


Okay, I appreciate that there's no built-in meta-unit that would permit me
to say "start me to the exclusion of absolutely everything else." I agree
that would fail the "what if two processes each tried to play that game?"
test.

I was just hoping that some unit exists that is synonymous with "the point
upon which all traditional systemd work is dependent." I suppose nothing
still exists matching that kind of weaker description? E.g., ".slice" or
something like that.

.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150420/6817e363/attachment.html>