Xe also has the logging problems entirely backwards. It is systemd where one has problems with log flooding. One example of a person suffering from this is http://unix.stackexchange.com/questions/208394/ . The daemontools convention, ironically, is to have multiple separate log streams, usually one per service, which cannot flood one another.
Restart behaviour sometimes is configurable, by the way. (-:
Re. resource limits, I meant more than just softlimit - cgroups CPU and network throttling.
Re. namespaces - sure, it doesn't have to be built in. But many people use it and it's convenient when it is.
I used the daemontools many years ago and remember fast cycling to be an issue which was worked around by manual pauses in run scripts. If it was fixed later - I'm glad it works.
But my main point was that daemontools worked great when we had simpler inits. Running it with inits which could restart makes sense. Running it with modern inits just doesn't give you anything interesting apart from another idle system process.
> resource limits
Daemontools includes the softlimit [1] helper.
> namespaces
It's not clear to me why this need be built in to a supervisor instead of being applied through generic helper programs such as unshare(1).
> daemontools will just keep restarting your process as fast as possible, taking 100% CPU if possible
supervise [2]: "It restarts ./run if ./run exits. It pauses for a second after starting ./run, so that it does not loop too quickly if ./run exits immediately." Simple and not configurable, sure, but should not hammer the CPU.
> support for syslog/journal rather than just local files
Daemontools svscan [3] "optionally starts a pair of supervise processes, one for a subdirectory s, one for s/log, with a pipe between them". The "s/log" script can do anything you wish, reading logs on stdin. If you use the included "multilog" program, then it's certainly geared toward writing local files, though it does include the ability to run arbitrary post-processor during rotation (which might, for example, fire off a job to copy the logs to an aggregator). Or you can not run multilog and just send the logs to syslog or whatever.
What I do myself is send save the logs locally using s6's multilog analog, s6-log, and also pipe them to a local syslog that forwards them to an aggregator outside my control.
And, in spite of newer supervisors adding more and more features beyond what daemontools provides, daemontools is still an awesome system that was 14 years ahead of its time.
[1] http://cr.yp.to/daemontools/softlimit.html
[2] http://cr.yp.to/daemontools/supervise.html
[3] http://cr.yp.to/daemontools/svscan.html