[systemd-devel] Boot ordering
hurikhan77 at gmail.com
Fri Mar 20 00:57:07 PDT 2015
Andrei Borzenkov <arvidjaar at gmail.com> schrieb:
> On Fri, Mar 20, 2015 at 1:56 AM, Kai Krakow <hurikhan77 at gmail.com> wrote:
>> The point is: Let's just find out why the "intuitive" way to solve the
>> OPs problem doesn't work out and find the right solution. Let's face it:
>> Trying to use targets as sysvinit runlevels equivalent is obviously not
>> the working way although it looks promising and intuitive at first
> sysinit.target and basic.target are exact equivalent of sysvinit
> runlevels - they are hard serialization points between groups of
> services so that systemd will not proceed with next group until all
> services in previous group are started. The difference is that these
> runlevels are hardcoded and not configurable. All that OP asked for
> was a way to make it more flexible and customizable.
Yes, you are right. Thanks for the pointer. I didn't realize that as part of
It still feels wrong to allow that because it will probably be overly mis-
used by others (which doesn't mean the OP's intent is wrong) to mimic
sysvinit behaviour and make systemd work no better than other init systems.
But from "man systemd.special" I don't read that intentionally being hard
serialization points. It clearly works this way because systemd
automatically adds depends to all services to run after basic.target for
example. But I think the design decision behind it was more of kind of a
work-around than actually having hard serialization points. Otherwise it
would probably not had become hard-coded.
And most of those targets seem to be only special because they are part of
udev rules or very early systemd initialization - making me think that,
without looking at source code, that sysinit.target is the only target that
by intent is serialized through means of code. For basic.target this looks
more like (the intentional) side-effect of ordering all other services after
But I understand the OPs request: it's not feasible to manually do the same
as basic.target for his proposed target - it just won't really work except
for well-defined system configurations. The question is if it is really
needed if one relies on implicit dependencies provided by systemd (a fuzzy
explanation like "sometimes you need to run something before something else"
just doesn't cut it without specifying what "some*" is, not the OP's answer,
tho). Currently I cannot think of a use case for a serialized extra target
but I'm open to happily learn about it.
Replies to list only preferred.
More information about the systemd-devel