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.
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://skarnet.org/software/s6/ [2] http://skarnet.org/software/execline/