Which is why systemd discourages daemonizing in the service and introduces both socket units (so that you can always connect to the server socket, you do not need to wait for the child to call bind(2)) and a simple notification protocol.

Socket activation is nice for certain things, like webservers. Unfortunately for other services socket activation can cause you far more headaches. For instance, Docker's default configuration used to be socket activated under systemd -- this was changed because it meant on-reboot that you wouldn't have any containers running until someone tried to do an administrative command (that used docker.sock).

Socket activation is more meant to allow for on-demand starting of services without losing connections -- and the design shows that this is the main purpose. For many services, "having a connection" doesn't mean the service is ready yet.

I think that having a notification system for a service to tell the init system it is ready would be nice, though the "obvious" way of doing it (rt signals) wouldn't work for unprivileged services.

But in systemd there's no reason you can't have a service enabled on boot and socket activation. It's a little redundant but it can be good to catch some corner cases: like you can always issue docker commands even if Docker isn't ready.

The systemd notification system uses sockets. See https://www.freedesktop.org/software/systemd/man/sd_notify.h...

It looks like it has grown a bit since the last time I saw the manpage...

Systemd can wait for dbus services to be fully ready instead of just process start. Iirc there is also a way to use the watchdog apis for this if you have other types of ipc than dbus.

The socket stuff isn't much of a win for correctness though, in fact it has new failure modes. It is one of these things that is confidently advertised as a great benefit of systemd, but it is actually a quite subtle matter and requires thinking. (Remember inetd?)

What if something else relies on the socket being open to mean that the service is fully running including e.g. side effects on disk? What if a service made on-demand with socket activation is supposed to have low latency on the first request? There is a reason why inetd disappeared long before systemd appeared. The saved memory (that is how long ago it was) wasn't worth the brittleness and complication anymore.

Then there are cases where a service is intentionally shut down for a critical operation of some kind but a client connects to the socket, auto-starting the service in the middle of the critical operation.

Debian hit this some years ago in its conversion to systemd. It took the existing van Smoorenburg rc notion of temporarily stopping services during a package upgrade and translated that in the straightforward manner to systemd units. People started hitting services that got restarted in the middle of a package upgrade, causing various unwanted side-effects. So the Debian mechanism had to be changed to detect the existence of systemd and stop/start the socket units as well as, or sometimes instead of depending from the service, the service units.

Package upgrades are not the only places where one hits this. It is important that socket/path/automount/timer units be stopped as part of the shutdown process, not just service units, otherwise one can end up with shut down services being started back up by the sockets/paths/automounts/timers late in the shutdown process, potentially deadlocking it, and at least lengthening it by a significant amount.

> So the Debian mechanism had to be changed to detect the existence of systemd and stop/start the socket units as well

Huh. You’d think the more correct thing to do would be to do “systemctl --runtime --now mask $service; $DO_THING; systemctl --runtime unmask $service; systemctl start $service”. Or, even more correct, first detect if the service is running, then do the above, except only start the service again if it was running previously.

It isn't, of course, for the reason already given.

In fact, the Debian people created two extra programs named deb-systemd-helper (with the same enable/disable/mask/unmask syntax as systemd's own systemctl) and deb-systemd-invoke (with the same start/stop/restart syntax as systemd's own systemctl) for performing all of these actions over package upgrades, employing a parallel set of service symbolic link farms.

* https://manpages.debian.org/stretch/init-system-helpers/deb-...

* https://manpages.debian.org/stretch/init-system-helpers/deb-...