[systemd-devel] Boot ordering
hurikhan77 at gmail.com
Thu Mar 19 14:04:22 PDT 2015
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
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.
Replies to list only preferred.
More information about the systemd-devel