On Thu, 29.01.15 17:20, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote:

> Hi all,
> I'd like to realize a staged startup with systemd which is mainly about:
> - starting up a static tree up to a final service
> - the only job of the final service is to kick off the start of an additional 
> sub tree of units
> This kind of startup could be realized simply by adding an additional one 
> shot service which executes: systemctl start xxx.target
> My question now is: Is this the appropriate way for realizing this
> or is there any other more elegant way. My problem with this
> approach is that systemd executes a binary (systemctl), which
> communicates with systemd just to queue a new job in systemd. Sounds
> as if there should be a way which is a bit more direct ...

This has come up before, for example here:


I think generally it is a better idea to push as many IO and CPU
workloads into the kernel as possible, plus appropriate scheduling
settings and let it figure out the rest, than trying to work around it
by pushing things into the kernel only bit-by-bit, like you would do
with such a "staged" startup.

We already added support for applying different scheduling settings
during startup then during normal operating to help with this.

What I'd still like to see changed in systemd proper is permitting the
user to control which job to execute first if multiple jobs are
runnable at the same time. Currently the order is undefined (though
not random).

If you really want to do a "staged" boot-up then invoking "systemctl
start --no-block" from a service is the option of choice I figure...


Lennart Poettering, Red Hat
systemd-devel mailing list

Reply via email to