> daemontools are nothing more than an init system on top of an init system
What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine).
I've been using s6 to manage a few things, and some features I like are:
- allow a group to manage (stop/restart) certain processes using Unix file permissions
- arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.
I have not tried runit. s6 is actively maintained; I don't know about runit (on the other hand, runit is in Debian while you must compile s6 yourself). The author of s6 has a (very biased of course) comparison or various supervisors:
The big feature s6 has that runit lacks seems to be the ability to wait without polling on some event (process started). I haven't used this much myself, but even given that some process has started, it doesn't necessarily mean that it's initialized and ready to do what you expect.
What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine).
http://www.skarnet.org/software/s6/index.html
I've been using s6 to manage a few things, and some features I like are:
- allow a group to manage (stop/restart) certain processes using Unix file permissions
- arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.