On Wed, Jan 09, 2019 at 06:00:31PM +0100, Simon Matter via CentOS wrote: > Maybe things _could_ be done the right way with systemd, but it doesn't > happen because it quickly starts to be very complex and it's a lot of work > to do it for a complete distribution. It just doesn't happen - or at least > did not happen in all the years since its introduction. There are a couple ways that systemd can handle service startup in a way that dependent services can gracefully start up after it. One way is to have systemd open the socket, then hand it to the service when it is ready. This requires quite a bit of hacking and I don't think is as reliable, it's more of the inetd way of doing things. Another is to have the code send a message when it is ready. This isn't really that complicated, you can look at the change in postgresql's git here: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7d17e683fcc28a1b371c7dd02935728cd2cbf9bf Basically, when the database is ready, it calls the C function: sd_notify(0, "READY=1"); and when it's shutting down, it runs: sd_notify(0, "STOPPING=1"); To be honest, that's not too complicated. It does require minor changes to the code to support systemd, but you can replace idle loops in shell scripts with a smarter database (which knows when it is ready) telling PID 1 that it is ready. -- Jonathan Billings <billings at negate.org>