[systemd-devel] Boot ordering

[Kai Krakow]

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

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

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.