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

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