Reindl Harald <h.rei...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
