supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Vincent Danen <vdanen@linsec.ca>
Subject: Re: /etc/runit vs /etc/sv vs /usr/share (Debian)
Date: Wed, 1 Feb 2006 10:15:45 -0700	[thread overview]
Message-ID: <20060201171545.GZ743@annvix.org> (raw)
In-Reply-To: <20060201145445.GA12654@dusk.harfang.homelinux.org>

[-- 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 --]

      parent reply	other threads:[~2006-02-01 17:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-01 13:54 Gilles
2006-02-01 14:28 ` Gerrit Pape
2006-02-01 14:54   ` Gilles
2006-02-01 15:33     ` Gerrit Pape
2006-02-01 17:52       ` Gilles
2006-02-01 17:15     ` Vincent Danen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060201171545.GZ743@annvix.org \
    --to=vdanen@linsec.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).