service definition vs service activation

["Wayne Marshall" <wcm@guinix.com>]

On Mon, 6 Mar 2006 16:05:27 +0000
Gerrit Pape <pape@smarden.org> wrote:

> ...  The documentation
> now suggest to put service directories by default into the /etc/sv/
> directory, and a list of frequently asked questions with answers
> has been added.

I find it useful to make an explicit distinction between the
directories used for service definition and service activation.

In this nomenclature the service definition directory refers to the
actual physical location of the run scripts, resources, and runtime data
files for a supervised service.  The service activation directory then
refers to a directory scanned by runsvdir (or svscan), into which
services defined in a service definition directory are selectively
symlinked.

The usual custom has been to use /service as the service activation
directory for daemontools services and /var/service as the service
activation directory for runit services.

On the other hand here has been no usual custom or consensus for the
service definition directory.  This is because services combine
attributes of things usually found elsewhere, such
as /etc, /etc/init.d, /var/run, and /var/log.  Service definitions by
their very nature don't exactly fit cleanly anywhere in the usual unix
hier(7) scheme of things.

For the purposes of consistency and making an explicit distinction
between definition and activation, my installations and documentation
are now standardized on the use of /var/service.d as the service
definition directory for all runit services. Then /var/service
continues its role as the primary service activation directory. 

For example:

 # cd /var/service
 # ls -l
 lrwxrwxrwx dropbear -> /var/service.d/dropbear/
 lrwxrwxrwx fnord -> /var/service.d/fnord/
 lrwxrwxrwx mailfront-pop3d -> /var/service.d/mailfront-pop3d/
 lrwxrwxrwx qmail-ofmipd -> /var/service.d/qmail-ofmipd/
 lrwxrwxrwx qmail-send -> /var/service.d/qmail-send/
 lrwxrwxrwx qmail-smtpd -> /var/service.d/qmail-smtpd/
 lrwxrwxrwx twoftpd-anon -> /var/service.d/twoftpd-anon/

Of course all of this is a matter of personal preference and site
policy.  I only mention it here because I believe there is some value
in making the distinction between definition and activation clear.

However I would also say that, no matter the naming conventions one
chooses, there is good reason for keeping service definition
directories on the /var partition.  Maybe this has been hashed to death
elsewhere, but on many systems the /var partition is specifically
suited to hosting log files and dynamic runtime data, while /etc is
usually on the root partition and configured for static data.

As I understand it, the documentation for this release of runit sort of
turns all this on its head.  Now /etc/sv is recommended as the service
definition directory, while /var/service continues as the service
activation directory.

I don't think I would mind too much if /etc/sv were suggested as the
service activation directory.  That would make a certain amount of
sense and I could even grow to like it.  You would then only have the
small problem of suggesting a service definition directory named
something other than /var/service, which on current installations will
be in use as the service activation directory.  Possible choices could
include /var/sv, /var/sv.d, or /var/service.d as mentioned above.

But /etc/sv on too many systems does make a poor choice for the service
definition directory.  Yes, I do know you could symlink /etc/sv back
to yet another directory on the /var partition, or even create a
separate /etc/sv partition with /var-like attributes.  Way too much
bother; it's hard enough to encourage people on the value of service
supervision as it is.

In summary, all this has just been a long-winded way of appealing
for a reconsideration of documenting /etc/sv as the service definition
directory for runit.

Many thanks to Geritt and all who are continuing to support the
development of runit and giving us a viable "way forward" from djb
software.

Wayne