Re: service definition vs service activation

Re: service definition vs service activation

[Joshua N Pritikin]

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

One further thought--

Wayne Marshall wrote:
> 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. 

This choice is madness since the two directories are so similarly named.
Is there any reason not to use /etc/ for the activation directory?
That's essentially what sysvinit does.

I suggest /etc/sv as the activation directory (and perhaps "single" or 
sv1 for single user mode) and somewhere under /var as the definition
directory.  Note that there may be various different definition
directories.  For example,

/var/runit-services/ssh
/var/runit-services/xdm
/var/runit-services/...etc...

/var/runit/local/remote-password-reset   # site specific

Hrm .. so I propose /var/runit as the definition tree.  There could be
various subdirectories for better organization.  For example, bcron
needs three services so:

/var/runit/bcron/sched
/var/runit/bcron/spool
/var/runit/bcron/update

This is an improvement on the current naming.  And socklog fits into
this scheme as well:

/var/runit/socklog/unix
/var/runit/socklog/klog
/var/runit/socklog/inet
/var/runit/socklog/ucspi-tcp

Now, does everybody hate this idea?  ;-)

-- 
Make April 15 just another day, visit http://fairtax.org

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

Re: service definition vs service activation

[Joshua N Pritikin]

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

On Tue, Mar 07, 2006 at 07:00:10PM +0530, Joshua N Pritikin wrote:
> I suggest /etc/sv as the activation directory (and perhaps "single" or 
> sv1 for single user mode)

/etc/sv     # symlink to sv1.d or sv2.d
/etc/sv1.d  # single user
/etc/sv2.d  # multi user

> /var/runit/bcron/sched
> /var/runit/bcron/spool
> /var/runit/bcron/update

Well, this doesn't work because the name of the service is the name
of the directory.  But it could still be

/var/runit/bcron/bcron-sched
..etc..

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

Re: service definition vs service activation

[Gerrit Pape]

On Tue, Mar 07, 2006 at 08:35:22PM +0200, Alex Efros wrote:
> 1)  Service definition directory can use symlinks to suit FHS:
> 	/etc/sv/SERVICE/supervise     -> /var/run/sv/SERVICE/
> 	/etc/sv/SERVICE/log/supervise -> /var/run/sv/SERVICE/log/
>     and ./log/run can start svlogd with /var/log/SERVICE/ as param.
>     
>     That way /etc/ will contain only static configuration files, while
>     logs and ./supervise/ dir will be on /var/.
>     Service activation directory is /var/service/ or /var/sv/.

This is what I would suggest too.  My personal preference is to have all
configurations of a service collected in a single directory, the service
directory is a nice place for that.  The only non-configuration files in
a service directory are in the ./supervise/ directories, and runit
allows you to make them symlinks, even dangling ones, to put them
anywhere on the filesystem you like.  The FHS doesn't reflect all my
personal preferences, but I adhere to it while Debian development; where
the FHS and by preferences differ, I use symlinks.

So, in my opinion, the /etc/sv/ directory is just fine to put the
services directories in, previously I put them into /etc/.

Regards, Gerrit.

Re: service definition vs service activation

[Joshua N Pritikin]

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

On Wed, Mar 08, 2006 at 10:40:44AM -0500, Christian Holtje wrote:
> Example:  add extra arguments to svlogd that tell it where to put the 
> "real" log files to...  svlogd could maintain symlinks from the real log 
> files to the /etc/sv/thingy/log/ directory.

Logs are already in /var/log/.  Only the log/run script is under /etc/.

Only the per-log config file is in the "wrong" place, under /var/log/.
Any config file belongs in /etc/, but I can't think of a non-kludge
way to keep the log config and logs separate.  It's just not worth it.
Keeping the logs & log config together is a clever design decision.

> I don't much care about the supervise being in /etc/sv/thingy...it's 
> annoying, but I can live with it.   The lock file is a little more 
> annoying, but it is just a part of svlog and probably can be moved as 
> well....

-- 
Make April 15 just another day, visit http://fairtax.org

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

Re: service definition vs service activation

[Christian Holtje]

Wayne Marshall wrote:
> 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.
>   
Maybe the dynamic data should be shunted elsewhere.

Example:  add extra arguments to svlogd that tell it where to put the 
"real" log files to...  svlogd could maintain symlinks from the real log 
files to the /etc/sv/thingy/log/ directory.

I don't much care about the supervise being in /etc/sv/thingy...it's 
annoying, but I can live with it.   The lock file is a little more 
annoying, but it is just a part of svlog and probably can be moved as 
well....

Ciao!

-- 
A man's only as old as the woman he feels.
	-- Groucho Marx

The Doctor What: Un-Humble                       http://docwhat.gerf.org/
docwhat *at* gerf *dot* org                                        KF6VNC

Re: service definition vs service activation

[Joshua N Pritikin]

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

On Tue, Mar 07, 2006 at 08:35:22PM +0200, Alex Efros wrote:
> 1)  Service definition directory can use symlinks to suit FHS:
> 	/etc/sv/SERVICE/supervise     -> /var/run/sv/SERVICE/
> 	/etc/sv/SERVICE/log/supervise -> /var/run/sv/SERVICE/log/
>     and ./log/run can start svlogd with /var/log/SERVICE/ as param.
>     
>     That way /etc/ will contain only static configuration files, while
>     logs and ./supervise/ dir will be on /var/.
>     Service activation directory is /var/service/ or /var/sv/.
> 
>     I've tried this way, and found myself always forget to create
>     ./supervise symlinks BEFORE I start new service and runsv will create
>     ./supervise directories instead. This can be easy solved by using
>     script to create service directories, of course.
> 
>     Ugly, but suit FHS.

I think that's too ugly for mere pedantic FHS compliance.

I'd prefer a small amount of read-only data on /var (run, finish, etc)
rather than confront symlink hell.  With symlinks, it is too comfusing
if the run script uses relative paths (eg. envdir ./config and the
like).

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

Re: service definition vs service activation

[Alex Efros]

Hi!

On Mon, Mar 06, 2006 at 11:13:38AM -0800, Wayne Marshall wrote:
> 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.

I'm mostly agree with your, but there exists two more alternatives:


1)  Service definition directory can use symlinks to suit FHS:
	/etc/sv/SERVICE/supervise     -> /var/run/sv/SERVICE/
	/etc/sv/SERVICE/log/supervise -> /var/run/sv/SERVICE/log/
    and ./log/run can start svlogd with /var/log/SERVICE/ as param.
    
    That way /etc/ will contain only static configuration files, while
    logs and ./supervise/ dir will be on /var/.
    Service activation directory is /var/service/ or /var/sv/.

    I've tried this way, and found myself always forget to create
    ./supervise symlinks BEFORE I start new service and runsv will create
    ./supervise directories instead. This can be easy solved by using
    script to create service directories, of course.

    Ugly, but suit FHS.


2)  DJB invented nice place where to create directories which is not suit FHS.
    In root. ;-) From this view, /sv/ or /service/ would be nice place for
    service definition directory, while /var/sv/ or /var/service/ is
    service activation directory.


P.S. I use /service/ as service definition directory, /var/service/ as service
activation directory, and ./log/run start svlogd with /var/log/SERVICE/ param.  

-- 
			WBR, Alex.

Re: service definition vs service activation

[Joshua N Pritikin]

On Mon, Mar 06, 2006 at 10:54:43PM +0100, Gilles wrote:
> > 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.
> 
> As I hinted in a previous post (but without giving the arguments as you
> did), I think I agree with you ;-)

Agreed.

The definitions need to be on a writable volume because of runsv's
supervise state.  /etc is not always writable.

Re: service definition vs service activation

[Gilles]

Hi.

> 
> 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.
>

As I hinted in a previous post (but without giving the arguments as you
did), I think I agree with you ;-)


Gilles

service definition vs service activation

[Wayne Marshall]

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