[systemd-devel] Boot ordering

[Kai Krakow]

Michael Biebl <mbiebl at gmail.com> schrieb:

> 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"

I think MySQL is broken in this regard as it signals the caller to be ready 
before actually being ready. I think I've read this is a known problem and 
that there are plans to support socket activation/socket passing in the 
future.

>> 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.

Ooops, yes Michael, you are perfectly right. If the process is forking, it 
will (at least should) return only when it is ready and then it makes 
perfect sense. This would not be possible with non-forking processes and 
those would need to resort to socket passing to actually "be ready" the very 
moment when started.

But for MySQL: It think it is simply not ready yet when returning to the 
caller - probably that's because the service spawner "mysqld_safe" is a 
script which also tries to handle the PID file etc etc. That design is 
simply broken in a modern world with fast computers because a fast computer 
may well be ready to serve requests that need mysql before mysql itself is 
done with its internal setup. And the script mixes in a lot of stuff that 
actually systemd should do (and traditional sysvinit start wouldn't usually 
do, so it's some sort of construct of convenience to fix sysvinit behavior).

-- 
Replies to list only preferred.