systemd sucks, but this feature isn't the worst thing in the world, even if it's primitive. Probably the best implementation I've seen is in erlang ( https://w

systemd sucks, but this feature isn't the worst thing in the world, even if it's primitive. Probably the best implementation I've seen is in erlang ( https://www.erlang.org/doc/design_principles/sup_princ.html https://www.erlang.org/doc/design_principles/sup_princ.html ) in which supervisor processes get notified of child death and can use several different strategies to figure out what to do next (e.g. die and expect the supervisor's supervisor to handle it, terminate all children and restart, ...) Although you do lose state when a process dies, if your processes are sufficiently lightweight and/or stateless, it's possible for the problem to be irrelevant until the next software release can garden/amend/curate it. The win that you get in erlang/elixir/etc. is that you can just code the happy path most of the time, and then figure out which sad paths are the ones you need to deal with once you've seen production under load. If you've ever programmed in go, you understand how freeing that is.