[systemd-devel] Boot ordering
hurikhan77 at gmail.com
Fri Mar 20 13:43:15 PDT 2015
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
>> 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.
More information about the systemd-devel