Importing djb's public domain daemontools?

[Jos Backus]

On Tue, Jan 17, 2012 at 3:52 PM, Tom Rhodes <trhodes at freebsd.org> wrote:

> [snip]
> That bug could be fixed (IIRC what it was) - and it does most of the
> legwork you're talking about, removing pidfile requirements would
> probably be trivial for someone with a free evening.  Regardless, I
> tried to find a common ground with launchd and nothing, the
> community is more than welcome to make changes.  Maybe I'll
> just test build and bring it in, then people can make it work the
> way they'd like.  ;)
>

I'm not opposed to this if the consensus is that we want to try this.

Here are some of the things I like about daemontools that I would want any
accepted solution to support, as I have actively used all these features in
the past:
- Decouple running of the service from the user controlling the service.
With daemontools, this is handled by the service run script being run by
supervise in response to a command sent across a UNIX domain socket. No
environment variables or other user state can leak into the service process
by default.
- The ability for arbitrary sets of (non-root) users to control a service.
With daemontools this can be achieved by manipulating the UNIX domain
socket permissions for a service.
- The ability to reliably deal with crashing processes and be able to take
action upon signals/non-zero exits. With daemontools-encore, the finish
script lets one fine-tune these cases, and standard daemontools can
automatically restart a service.
- Simple command interface to bring a service up or down, up once
(one-shot) or send signals. With daemontools, the svc command is used for
this.
- Simple command interface to see the status of a service, including its
uptime and pending status. E.g. with daemontools, svstat will display
service status and uptime, including if a service wants to go down.
- Simple service configuration. In daemontools, the file system is used.
This makes it possible to use tools such as `echo', `rm' and `ln -s' to
manipulate and configure services independently from each other. I don't
like a single shared configuration file such as /etc/inittab because it
makes it difficult to edit services safely as the wrong edit can affect all
services (think Puppet). E.g. with daemontools, enabling a service can be
as simple as an `ln -s' command. Editing the state of one service should
not be able to affect any other service.
- Handle logging of stdout/stderr. daemontools uses the associated log
service for this, usually with multilog.
- No reliance on pidfiles. In daemontools, supervise is the parent of a
service so it already knows its child's pid.

If fsc can be made to do all these things too and we feel more comfortable
with it than importing daemontools, that's great.

Jos

-- 
Jos Backus
jos at catnook.com