[systemd-devel] Boot ordering

[Kai Krakow]

Christoph Pleger <Christoph.Pleger at cs.tu-dortmund.de> schrieb:

> I am experimenting a little with systemd and trying to define a new
> "intermediate" runlevel, a runlevel between basic.target and
> multi-user.target. This means that I want the services which are required
> by my new runlevel to be started after all services from basic.target have
> been started and to be finished before any service from multi-user.target
> is started.

I think there is still this sysvinit-related misconception that systemd 
target equal sysvinit runlevels.

Systemd uses automatic ordering of units through socket activation and 
explicitly defined dependencies (which BTW most of the time are not needed). 
Thus, a target just defines which set of services you want to run asap. 
Multiple targets can become active in parallel, and systemd will try to 
reach them in parallel. All dependencies will be thrown into the same soup 
and systemd works its way through it.

The runlevels as used by sysvinit were just there because its design of 
dependencies was virtually non-existent - or at least broken. Because there 
were no real dependencies, it had runlevels: points in time of the boot 
process to ensure that services which were more or less unrelated by means 
of dependencies could be run in a more or less defined order or maybe even 
in parallel (well, the "parallel" concept was exploitet by later 
incarnations of the sysvinit concept). But still the "runlevel" was a well 
definied point in time which explicitly decoupled services from each other 
in time which had strong dependencies on each other - like the presence of a 
fully mounted file system.

Systemd usually does not need it: It uses automounts and socket activation 
(and probably other less obvious mechanics) to decouple service dependencies 
(which allows a myriad of other nice advantages which are a little out of 
scope here).

So, to get the result you are expecting, you should first try to get away 
from the concept of runlevels and rethink the finer grained dependencies of 
whatever you are trying to achieve. If your service/process/whatever needs 
the presence of specific services you need to either explicitly mention them 
as dependency or try to make socket activation and automounts work for you. 
Then you have to find a way to block everything else that conflicts with 
your service/process/whatever to wait, until your actions are done. If it is 
well thought and well designed, it probably boils down to less work than you 
think it currently sounds like. In the end, systemd is much different to 
sysvinit in the sense of that you can actually rely on services/filesystems 
being ready to use the very moment you use them without bothering 
dependencies - because otherwise your process would simply block until 
systemd is ready to serve them.

But trying to use targets as runlevels (in the spirit of sysvinit) is 
clearly the wrong road, causes headaches, and calls for trouble later.

What you are looking for is probably something like a staged startup which 
has been discussed here before. I don't remember the outcome though, you 
have to research yourself. I'd just like to throw it in as a pointer while I 
remembered it, hope you can find some answers that way.

Maybe you could also expect better help here if you just clearly tell why 
you need to wait on what to finish, and why you need to block what until 
your process is done with... which tasks anyway? I think people are really 
up to helping you but they cannot because you describe your problem, well... 
in a very fuzzy way. This only results in clueless people on both sides with 
one side thinking systemd is really bad design - but it is not. It is very 
well designed, at least according to my experience with it and solving 
problems with it.

In a way, systemd works like pure magic for me. But magic is just a 
technology we're not yet fully understanding. And that said, I'd really like 
to just learn more about it. And in this sense, I'm interested in your exact 
problem. While I may not solve it, following its solution will help me 
understand better. ;-) I think other readers feel the same.

Thanks. :-)

-- 
Replies to list only preferred.