[systemd-devel] Boot ordering

[Michael Biebl]

2015-03-20 9:12 GMT+01:00 Reindl Harald <h.reindl at thelounge.net>:
>
> Am 19.03.2015 um 23:56 schrieb Kai Krakow:
>
>> Reindl Harald <h.reindl at thelounge.net> schrieb:
>>
>>> Am 19.03.2015 um 22:04 schrieb 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
>>>
>>>
>>> that is all fine but given that you don't know when a service is ready
>>> to accept connections and the whole world don't turn around systemd it
>>> is a legit need to control ordering sometimes strictly
>>
>>
>> Well I don't see where the conflict is. Double-forking services should
>> probably just not return to the caller until they are ready to accept
>> connections. This is why you should design your service units for systemd
>> to
>> not fork but start the process in foreground (most services have a cmdline
>> option for that since years)

Hm, this is a misunderstanding.
Traditional daemons are supposed to be written in a way, that they
setup all communication channels, and then fork.
So the fork (or rather the exit of the parent process), was the
signal, that the daemon is ready to accept connections.

If your daemon doesn't use sd_notify or e.g. grabs a D-Bus name, I
actually it's better keep using Type=forking instead of simple for the
reasons Reindl mentioned.


> i guess that's whay mysqld needs
> "ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID" having a shell
> script waitig in a lopp until connections are accepted to prevent services
> with "After=mysqld"
>
> with foreground you have *no control at all* becasue systemd fires up the
> next service immediately, frankly systemd even don't know the startup time
> of "Type=simple" services, hence they are missing in "systemd-anlyze blame"

Right,  if a service needs to setup communication channels etc. for
other services to talk to, then imho simple is not the best choice as
you need to resort to hacks like you describe.
Ideally, mysql would use sd_notify, Type=forking is probably the next best.


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?