/etc/runit vs /etc/sv vs /usr/share (Debian)

/etc/runit vs /etc/sv vs /usr/share (Debian)

[Gilles]

Hello.

The "runit" documentation on the web site seems to
recommend to install the service directory below
"/etc/runit", while the new "runit-services" (for
Debian) installs them in "/etc/sv".
Why the difference?

Since not all services proposed by the package are
necessarily going to be actually used on the system,
wouldn't it be more appropriate not to locate them
in "/etc"?  E.g. many examples of scripts proposed
by packages are below "/usr/share".


Best regards,
Gilles

Re: /etc/runit vs /etc/sv vs /usr/share (Debian)

[Gerrit Pape]

On Wed, Feb 01, 2006 at 02:54:09PM +0100, Gilles wrote:
> The "runit" documentation on the web site seems to
> recommend to install the service directory below
> "/etc/runit", while the new "runit-services" (for

I don't think it recommends it, but puts the default getty-5 service
directory in there, yes.

> Debian) installs them in "/etc/sv".
> Why the difference?

/etc/runit/ also is the place for the stage 1,2,3 scripts, and the magic
files stopit, reboot, ctrlaltdel.  I don't think it's a good place to
put the service directories.  Initially I thought they should just go
into /etc/, but in the style of the new sv program, I decided to now
recommend the /etc/sv/ directory.  I'm in the progress of moving the
getty-? service directories and other (such as provided by socklog-run,
bcron-run, twoftpd-run, ...) into /etc/sv/ too.

After all it's just personal preference.  I prefer to have the service's
configuration (including run scripts) and logs all accessible through a
single directory, now /etc/sv/<service>/.

/usr/share/ should be good for examples or template service directories,
but for actual use, they should be somewhere in /etc/, where
configuration files usually belong.

Regards, Gerrit.

Re: /etc/runit vs /etc/sv vs /usr/share (Debian)

[Gilles]

Hi.

> > The "runit" documentation on the web site seems to
> > recommend to install the service directory below
> > "/etc/runit", while the new "runit-services" (for
> 
> I don't think it recommends it, but puts the default getty-5 service
> directory in there, yes.
> 

As the first reading on how things should be set up, maybe this page
should be updated.

> > Debian) installs them in "/etc/sv".
> > Why the difference?
> 
> /etc/runit/ also is the place for the stage 1,2,3 scripts, and the magic
> files stopit, reboot, ctrlaltdel.  I don't think it's a good place to
> put the service directories. 

Again, the above page makes one think that you think the opposite.

> Initially I thought they should just go
> into /etc/, 

But that would have mixed with the server programs config files!  No?

> but in the style of the new sv program, I decided to now
> recommend the /etc/sv/ directory.  I'm in the progress of moving the
> getty-? service directories and other (such as provided by socklog-run,
> bcron-run, twoftpd-run, ...) into /etc/sv/ too.
>

But why having some services in their own package "<service>-run" and
others mixed in "runit-services"?

> After all it's just personal preference.  I prefer to have the service's
> configuration (including run scripts) and logs all accessible through a
> single directory, now /etc/sv/<service>/.
> 

Definitely fine for "run" and "log/run", but do you really recommend having
the log files in there too?  Those files can grow and eat a large amount
of the root partition's space!  I thought a better place would be

  /var/log/service/<service>

or with the newly proposed name

  /var/log/sv/<service>

> /usr/share/ should be good for examples or template service directories,
> but for actual use, they should be somewhere in /etc/, where
> configuration files usually belong.
> 

There, you said "for actual use", which was exactly my point in the
previous mail:  Not all services in the package "runit-services"
will be actually installed on the system:  For those unwanted services,
having a directory under "/etc/sv" might be construed as a little
bit "messy" (or at best, misleading).


Best,
Gilles

Re: /etc/runit vs /etc/sv vs /usr/share (Debian)

[Gerrit Pape]

On Wed, Feb 01, 2006 at 03:54:45PM +0100, Gilles wrote:
> > but in the style of the new sv program, I decided to now
> > recommend the /etc/sv/ directory.  I'm in the progress of moving the
> > getty-? service directories and other (such as provided by socklog-run,
> > bcron-run, twoftpd-run, ...) into /etc/sv/ too.
> 
> But why having some services in their own package "<service>-run" and
> others mixed in "runit-services"?

While I can provide a socklog-run package, I don't have control over
the 'other' packages.  And I'm afraid it's not that easy to convince
maintainers of 'other' packages to provide such a *-run package, at
least not short-term.  So the runit-services package is a (interims)
place to make the service directories available conveniently.  I would
be happy to remove them once they appear in a <service>-run package.
One could try by filing wishlist bugs against the corresponding
packages.

> > After all it's just personal preference.  I prefer to have the service's
> > configuration (including run scripts) and logs all accessible through a
> > single directory, now /etc/sv/<service>/.
> 
> Definitely fine for "run" and "log/run", but do you really recommend having
> the log files in there too?  Those files can grow and eat a large amount
> of the root partition's space!  I thought a better place would be

No, I recommend to have them _accessible_ through the service directory,
think of symlinks.

> > /usr/share/ should be good for examples or template service directories,
> > but for actual use, they should be somewhere in /etc/, where
> > configuration files usually belong.
> 
> There, you said "for actual use", which was exactly my point in the
> previous mail:  Not all services in the package "runit-services"
> will be actually installed on the system:  For those unwanted services,
> having a directory under "/etc/sv" might be construed as a little
> bit "messy" (or at best, misleading).

Maybe.  I personally don't care that much, and don't link them into
/var/service/.

Regards, Gerrit.

Re: /etc/runit vs /etc/sv vs /usr/share (Debian)

[Gilles]

> 
> While I can provide a socklog-run package, I don't have control over
> the 'other' packages.  And I'm afraid it's not that easy to convince
> maintainers of 'other' packages to provide such a *-run package, at
> least not short-term. 

Why does the maintainer of a new "<service>-run" package have to be
the same person of package "<service>"?

> 
> > > After all it's just personal preference.  I prefer to have the service's
> > > configuration (including run scripts) and logs all accessible through a
> > > single directory, now /etc/sv/<service>/.
> > 
> > Definitely fine for "run" and "log/run", but do you really recommend having
> > the log files in there too?  Those files can grow and eat a large amount
> > of the root partition's space!  I thought a better place would be
> 
> No, I recommend to have them _accessible_ through the service directory,

Why?

> think of symlinks.
>

You mean that the log "directories" in "/etc/sv" should be symlinks to
directories on another partition?

> > [...]  For those unwanted services,
> > having a directory under "/etc/sv" might be construed as a little
> > bit "messy" (or at best, misleading).
> 
> Maybe.  I personally don't care that much, and don't link them into
> /var/service/.
>

Well, if you don't care, and if in the ideal future, the "runit-services"
should disappear, I think that it's 2 more reasons for putting these in
"/usr/share". [I just feel that unused things in "/etc" in untidy ;-)]

Maybe a wish-list item?


Best,
Gilles

Re: /etc/runit vs /etc/sv vs /usr/share (Debian)

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

* Gilles <gilles@harfang.homelinux.org> [2006-02-01 15:54:45 +0100]:

[...]
> > After all it's just personal preference.  I prefer to have the service's
> > configuration (including run scripts) and logs all accessible through a
> > single directory, now /etc/sv/<service>/.
> > 
> 
> Definitely fine for "run" and "log/run", but do you really recommend having
> the log files in there too?  Those files can grow and eat a large amount
> of the root partition's space!  I thought a better place would be
> 
>   /var/log/service/<service>
> 
> or with the newly proposed name
> 
>   /var/log/sv/<service>

For Annvix, which uses runit as init by default, we do things a bit
different, but similar to the above.

All packages, once they're installed create /var/service/foo and
/var/service/foo/log with the appropriate run scripts in them.  This is
where they go, by default, and this isn't supervised.

We have our own tool called srv that manages things like dependencies,
starting and stopping services, etc.  When we add a service (srv --add
foo) it creates a symlink in /service; and /service is the directory
tree that is actually supervised.  To remove a service, just remove the
symlink (well, srv --del foo is cleaner).

Anyways, all of our logging scripts look similar to this:

[vdanen@build SPECS]$ cat ../SOURCES/mdadm-log.run 
#!/bin/execlineb

# logging for the mdadm service

/bin/foreground { /usr/bin/install -m 0700 -d -o logger -g logger /var/log/service/mdadm }
/bin/cd /var/log/service
/sbin/chpst -u logger /sbin/svlogd -tt /var/log/service/mdadm

So all of our logs go in /var/log/service/foo.

I find this is much cleaner because /etc should be used for
configuration files and while people can argue that a run script is
actually a configuration file (we flag it as such in our rpm packages so
that run scripts don't get overwritten if people make modifications to
it), there is other stuff, as you mention, that doesn't belong in
/etc... supervision state files, logs, and so forth.

The same argument goes for /usr/share... great for templates, but I
wouldn't run a service out of /usr... that's what /var is for.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]