[systemd-devel] Starting configurable set of services first

[Lennart Poettering]

On Tue, 02.09.14 10:06, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> Hi,
> 
> I would like to start a configurable set of services first and the
> services are wanted by multi-user.target. I am using a service to jump
> to multi-user.target and I was wondering if we can support this use
> case natively by systemd.
> 
> multi-user.target.wants
>   A.service
>   B.service
>   C.service
>   D.service
> 
> default.target > stage.target
> stage.target.wants (These are set by generator)
>   A.service
>   C.service
>   switcher.service
> 
> switcher.service (This is generated by generator)
>   [Unit]
>   Description=Switch to multi-user.targe
>   After=A.service C.service
>   [Service]
>   Type=oneshot
>   RemainAfterExit=yes
>   ExecStart=/usr/bin/systemctl --no-block start multi-user.target
> 
> This way I am jumping from one target to another target during runtime.
> 
> - What stage.target wants is dynamic. If it was static, my job would
> have been very simple.
> - I am aware of StartupCPUShares but it is not the ultimate solution
> A) there is a configurable minimum quota in CFS which still gives CPU
> to other processes. B) We still fork other processes and this causes
> changes in timeout values of other processes.
> - Adding dynamically After= to B and D service files is not the
> ultimate solution either because B and D might be socket/dbus
> activated by A or C.
> 
> Should this be something we should support natively by systemd?

As discussed at th systemd hackfest: I am a bit conservative about
this as it introduces plenty chance for deadlocks, where services
might trigger/request some other unit but we'd delay it until the
later stage...

I think the implementation you chose is actually pretty good. I am not
sure though that we should do this upstream. I mean, I really would
prefer if we'd dump as much work as possible on the IO elevator and
CPU scheduler, and then adjust the priorities of it to give hints what
matters more. Trying to second-guess the elevator and scheduler in
userspace feels a bit like chickening out to me, even though I am sure
that it might be something that one has to do for now, in the real
world...

There's one change I'd really like to see done though in systemd, that
might make things nicer for you. Currently, it's undefined in systemd
which job is dispatched first, if multiple jobs can be executed. That
means when we are about to fork off a number of processes there's no
way to control which one gets forked off first. I'd be willing to
merge a patch that turns this into a prioq, so that some priority
value can be configured (or automatically derived) for each unit, and
the one with the highest priority would win, and be processed
first. This would not provide you with everything what you want, but
would make things a bit nicer when we dump all possible work on the
scheduler/elevator, because after all we cannot really dump all work
at the same time, and hence should at least give you control in which
order to dump it, if you follow what I mean.

Lennart

-- 
Lennart Poettering, Red Hat