Re: daemontools respin?

Hi Bruce,

Here is my feedback on your initiative

I think that you've hit right on some of the features that daemontools 
is missing.

For some years now I've hacked on a alternative - but still compatible - 
daemontools implementation.

Unfortunatly I'm not in a position to share the sources since my 
employer "owns" this piece of work - but I'm allowed to share my ideas ;-)

I've also had the need to supervisors using service definitions from a 
readonly filesystem.

Also another feature that I've been adding to my own supervisor is start 
stop/crash notifications.

Since the supervisor can obtain the exitcode and signal-code of its 
supervised child and combine it with supervisors own service-runstate 
info - it can easily conclude if the service have crashed or was 
gracefully shutdown.

All this info: timestamp, start/stop/crash, up-/down-time, exitcode, 
crash/signalcode etc is sent as cmdline args to a "notify" program - if 
present in the current service dir.

A global (unified) "notify" program is called if no local "notify" 
program exists. Notifications can be turned off per service by touching 
".no_notify" in the current service dir.

As most of you may have guessed by now - this notification feature is 
used to do reporting to a centralized monitoring system.

My supervisor also implements a per service configurable 
crash-restart-policy. If a service crashes a given number of times 
within a given timeframe the supervisor will give up and permanently 
"down" the service in question. The previously mentioned notification 
feature is also used here to inform about the permanent state change 
(down).


BTW: have you looked at Gerrit Pape's runit ? http://smarden.org/runit/

He did a smart thing compared to daemontools - his supervisor (runsv) is 
able to supervise both the service and the logger within one process.
This reduces the number of supervisors and thus gives a simpler process 
tree - as far as I can see at no cost.

Kind regards Uffe Jakobsen