Debian reconsiders init-system diversity

Posted Nov 28, 2019 2:39 UTC (Thu) by flussence (guest, #85566)
In reply to: Debian reconsiders init-system diversity by Cyberax
Parent article: Debian reconsiders init-system diversity

I guess all my systems just vanished in a puff of logic then.

Debian reconsiders init-system diversity

Posted Nov 28, 2019 7:18 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Yep. Pretty much.

runit can't handle classic double-forking daemons. Fortunately, because of systemd most daemons these days have a foreground mode.

Debian reconsiders init-system diversity

Posted Nov 28, 2019 8:09 UTC (Thu) by smurf (subscriber, #17840) [Link]

I think most (if not all) of them had a foreground mode before systemd, for logging to the stderr / debugging etc..

Happily the once-common failure mode of

* daemonize, which involves …
* redirecting stdout+stderr to /dev/null
* the daemon or one of its libraries runs into a problem
* part/all of the problem/crash report is written to, you guessed it, standard error

is a thing of the past. Don't ask me how often I found that kind of thing with strace.

Debian reconsiders init-system diversity

Posted Nov 29, 2019 3:55 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

djb's daemontools had a workaround for that. I've never used it though, as I've never encountered anything that misbehaved in that way. The only problem I've had was with nfsd, and that's not a real daemon anyway.

Debian reconsiders init-system diversity

Posted Nov 29, 2019 6:12 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I remember that it used Unix process groups to track the double-forked daemons (cgroups-lite, lol). But it did not work reliably if the daemon itself tried to use process groups. This was not uncommon, and usually utilized for the same purpose - to track its own children.