[systemd-devel] Boot ordering

[Reindl Harald]

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)

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"

P.S.: one identical answer on-list would have been enough

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150320/300d717a/attachment.sig>