Does anyone have any insight in to why something like runit[1] was never a serious candidate for a sysvinit replacement in any mainstream Linux distro?
- There's a general opposition to the djb's designs and tools, which has some basis in their licensing, and is why djbdns and qmail aren't in the default distro of most systems. Note that this is being reversed right now with the embrace of NaCL crypto (Salsa20/ChaCha/Poly1305, etc.) as alternatives to the mainstream.
- runit is pretty much an reimplementation of djb's daemontools for service supervision.
- runit/daemontools definitely do things their own way. Service directories make sense, but they tend to be shell scripts all the way down. Logging is quite different and non-centralized. Services need to be set not to fork and do their own daemon management. And the list tends to go on - this unusual-ness is generally not what people want from a core OS part.
So, in short, there's no reason why people haven't used runit, other than "nobody else is doing it" and "it's different and has quirks".
Note that both djbdns and qmail have been in the public domain for years now. The general opposition to their license seems to have long outlived their license.
I think that's more related to the non-unified, pre-DVCS patch centric model of development, and the fact that djb has better things to do/is no longer interested in developing them.
If djb would have found an interested party to accept patches to the codebase, set it up on a code hosting site, then declared "this is the main repo for continuation of djbdns/qmail development", it would have gone a lot further than just "it's in the public domain" and no other guidance.
I agree with your points, though am disappointed by this reality. I've been aware of daemontools for some years, but only recently read over the design (which I find quite brilliant) and began using an implementation (s6 at the monent [1]).
I know you weren't arguing against daemontools, but just wanted to share some thoughts:
> Service directories make sense, but they tend to be shell scripts all the way down
This is true, but what are you doing in your "run" script that is so complex? Also, any executable will suffice. s6 provides 'execline' [2] which simplifies some use cases (and complicates others...)
> Logging is quite different and non-centralized
Arguably a feature. I'm quite enjoying the "logging chain" where every service logs to stderr which either goes to its specific logger process or bubbles up to that of the parent process.
The typical usage of syslog is to collect all log messages in a centralized inbox and then (by some pattern matching; log messages must contain enough to be categorized) split them up again and write them to separate files. Skip all that with logger-per-service.
> Services need to be set not to fork and do their own daemon management.
Clearly a feature. There is no need for the redundancy of multiple, error-prone implementations of daemonization routines in every service. Also, language nitpick, it's not that a service can't fork. For example, daemontools can happily supervise a Unicorn master process that will fork off its own workers. The service must not background itself by severing ties with its parent (which involves forking of course).
But there are downsides and quirks as you say. Two examples:
If you really want something like Nginx or Unicorn to be able to restart without dropping http connections (e.g. fork+exec new master process, gracefully shutdown and kill old master process), then you will run into issues. It's possible to hackishly wrap this in a helper script. Daemontools would supervise the helper, which would in turn manage nginx via plain old racy PID files, just like init.d scripts.
I'm only familiar with daemontools and s6, but they assume TERM is the signal to use to stop a service, and don't provide configuration to send, say, QUIT which Unicorn interprets as "graceful shutdown". (Upstart also did not allow this until fairly recent versions.) It's one thing to get a service to not daemonize itself. It's another thing to expect upstream to modify its signal handling.
[1] - http://smarden.org/runit/