Importing djb's public domain daemontools?

[David Xu]

On 2012/1/18 5:47, Jos Backus wrote:
> 2012/1/17 Dag-Erling Smørgrav<des at des.no>
>
>> Jos Backus<jos at catnook.com>  writes:
>>> If FreeBSD had a solid solution out of the box, all this pidfile hackery
>> in
>>> the base system wouldn't be necessary. I always thought FreeBSD was about
>>> good engineering. Perpetuating the pidfile mess in the base is not a sign
>>> of good engineering.
>> Software written by DJB hardly qualifies as "good engineering".  PID
>> files are well-known and well-tested, we have a solid implementation
>> with a simple API (pidfile(3)), and a lot of our infrastructure depends
>> on them (/etc/rc, newsyslog etc.)
>>
> Just because lots of people have been doing something for a long time that
> is widely supported, doesn't mean it's the right thing to do.
>
> As I said before, pidfiles export partial information that is already
> available in the process table, without requiring extra cached file system
> copies that need to be created/removed, have their permissions managed
> carefully and can get stale. daemontools is one implementation that solves
> the same problem without using pidfiles. It also gives you the option of a
> well-defined startup environment for each service (not tied to the
> environment of the caller) and the ability to add fine-grained control over
> a service (by manipulating the permissions on the control socket, so select
> non-root users can start root services if desired). It also comes with
> built-in logging (multilog). Additionally, using the finish script
> functionality, policies around crashes can be instituted (e.g. down the
> service and send an alert if it crashes more than N times within M
> minutes). These are just some of the features that I have used in the past
> to run services on hundreds of machines in multiple data centers.
>
> daemontools is surprisingly flexible, and it doesn't require complex
> configuration commands or configuration files - a boon when used in
> combination with tools like Puppet. That said, I don't care what we pick as
> long as we pick something that can do all the above.
>
> Jos
>
This sounds like a very cool tool, looks like these ideas are widely 
adopted,
I found some of the concepts are also in erlang OTP. ;-)

Regards,
David Xu