What 'dependency' means in Unix init systems is underspecified

Re:What 'dependency' means in Unix init systems is underspec... by ahartmetz on Sunday October 28, 2018 @04:46AM (#18319720)

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.

[ Parent | on HN ]

Re:What 'dependency' means in Unix init systems is underspec... by JdeBP on Sunday October 28, 2018 @07:09AM (#18320131)

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.

[ Parent | on HN ]

Re:What 'dependency' means in Unix init systems is underspec... by teddyh on Sunday October 28, 2018 @11:24AM (#18321011)

> 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.

[ Parent | on HN ]

Re:What 'dependency' means in Unix init systems is underspec... by JdeBP on Monday November 05, 2018 @06:46AM (#18381555)

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-...

[ Parent | on HN ]