[systemd-devel] Boot ordering

[Kai Krakow]

Reindl Harald <h.reindl at thelounge.net> schrieb:

> 
> Am 20.03.2015 um 21:10 schrieb Kai Krakow:
>>>> 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.
> 
> no - you refuse to understand that "Type=simple" (which is forground)
> just starts the binary and since there is no forking there is no
> knowledge when it is ready or that it can be ready for whatever
> 
> it is just a process running and that's it

Yes I understand it. It is logical consequence that Type=simple cannot let 
systemd know when the process is actually ready or what startup time it had.

And yes, mysql is using Type=simple but probably just because it uses that 
script mysqld_safe to start which tries to do all sorts of things to 
properly support sysvinit, but additionally other unrelated things.

Maybe mysqld-wait-ready should simply be properly integrated into 
mysqld_safe so that mysqld_safe would do it's work in the background by 
forking and the script returns when mysqld-wait-ready returns. Then, the 
systemd service file could resort to use Type=forking. The main problem here 
is probably that you cannot easily detacht processes from a shells job 
control so the start script would never return unless all children exited.

Which in turn means: The mysqld startup process is broken by design.

>>>> 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.
> 
> well, you where the one which said "start processes in foreground is the
> sultion and recommended"

Yes, and I said I'm also here to learn. Let's change that to "it's 
recommended if your service implements socket activation / socket passing".

> the point is just that a non-forking process without socket activation
> has no change to state anything and socket activation has it's other
> drawbacks like "if i say sysetmctl stop i mean systemctl stop and not
> fire the service up again if a packet arrives on the socket"

I suppose one usually should stop the socket to prevent further startups. 
But you are right that this would not be the principle of least surprise: If 
I stop a service I usually expect it to be stopped and stay that way.

> PLEASE stop to hang on mysqld, i just explained why staring a service in
> foreground don't help in any case, the opposite is true, hence i changed
> the clamd-service which is default forground started to forking to order
> clamav-milter correctly (just another *example*)

Yes, I'm getting the point.

BTW: I'd be interested in your solution about removing mysqld_safe. Can I 
just change the distribution service file, set the right user/group - or do 
I need to take care of any other stuff that mysqld_safe prepares/does?

-- 
Replies to list only preferred.