Re: Configuration services

[Laurent Bercot <ska-supervision@skarnet.org>]

> I want to be able to have other services depend on it.
> (cut)
> I also have a ./finish script that undoes all the configuration

 ... and if a stray signal happens to kill your shell, your "service"
will be deconfigured and reconfigured.
 The supervisor is there to ensure a process remains up no matter what;
it's suppoed to maintain a *process*, not a *state*. The only state it
can guarantee is 'want up', i.e. if the process ever goes down, you can
be sure it will be run again.

 You are not the first to want to use the daemontools/runit pattern as
a dependency manager, implementing a wider notion of 'service' than it
really does. As far as I can tell, this is not a very good idea - it
can be made to work, but it's generally shaky and unsatisfying. As a
rule of thumb, whenever you have a loop in your run script, you are
probably abusing the pattern.

 The supervision tree that svscan/supervise or runsvdir/runsv gives
you is a *process* tree; and the whole system is about supervising
*processes*. DJB started naming 'services' the supervised processes
because most services can be implemented via a run script setting up
some environment and executing into a daemon; but it's obvious that
people have a wider definition of 'service'. For instance, keeping
a net interface up should legitimately be called a service, but most
Unix implementations do not need a process that runs constantly to
achieve that; and *adding* a process to be controlled by a supervisor
to emulate a down/up service state is resource-consuming (even if
it's as light as a "sleep" binary) and should not be needed. It's
trying to fit a square peg into a round hole.

 Don't misunderstand me, I'm a fervent advocate of daemontools/runit,
and I believe it's a wonderful pattern, a necessary basis of any
reliable Unix implementation, and a very sound *fundation* for a
dependency management system. But per se, it's not a dependency
management system: it's a process management system. What we need
is another piece of software, using the supervision tree as an
underlying layer, that does proper dependency management and handles
a wider notion of 'service' than daemontools/runit.

 As far as I know, such a piece of software still remains to be written.
In the meantime, you can certainly use daemontools/runit as a service
dependency manager, but there *will* be holes and awkwardnesses in your
system, and you're going to have to consume extra resources to make it
work.

-- 
 Laurent