supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Rehan Khan <rehan.khan@dsl.pipex.com>
To: supervision@list.skarnet.org
Subject: non-daemon services/scripts as dependancies
Date: Sun, 23 Dec 2007 04:31:00 +0000 (UTC)	[thread overview]
Message-ID: <loom.20071223T025203-262@post.gmane.org> (raw)

Hi

I am trying to implement the facility names of the LSB 3.1 specification 
chapter 20.6. This requires that when certain 'facilities' like the local 
filesystem are available other services can depend on them.

The LSB spec says:

    Boot facilities are used to indicate dependencies in initialization 
scripts, as defined in Comment Conventions for Init Scripts. Facility names 
are assigned to scripts by the Provides: keyword. Facility names that begin 
with a dollar sign ('$') are reserved system facility names. Note: Facility 
names are only recognized in the context of the init script comment block and 
are not available in the body of the init script. In particular, the use of 
the leading '$' character does not imply system facility names are subject to 
shell variable expansion, since they appear inside comments. Conforming 
applications shall not provide facilities that begin with a dollar sign.
Implementations shall provide the following facility names:
$local_fs
$network
$named
.
..
... 

Each of these facilities can have many providers e.g. $named can be provided 
by bind, powerdns, djbdns etc and some cannot be run as supervised services 
e.g. $local_fs as they are just straight configuration scripts.

One way I can do this is have some sort of global variable or data structure 
where each script can register it's 'provides' facility name (good for 
$local_fs, $network). Another way is to create a service for each facility or 
name the symlink as the facility name but the service directory as the real 
name of the application so that one can see clearly which service is providing 
the facility (good for named, djbdns etc). 

To mix it up some more, sometimes a facility can be provided by multiple 
services which can also run at the same time without affecting the other 
service.

One of the main issues I am tussling with is tasks that *can* be implemented 
as non-supervised services and must run only once. There does not seem to be a 
simple/universal way to tell runsvdir to run a service only once (and not 
expect it to run a continuous process and if it returns succesfully on that 
first run then to tell other services that the service ran successfully. I 
realise that this is out of the scope of the primary function of runit but it 
would be very useful when trying to meet the lsb requirements.

I wanted to know if anyone has any ideas on how this can be implemented 
further?





             reply	other threads:[~2007-12-23  4:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-23  4:31 Rehan Khan [this message]
2007-12-30 22:27 ` Charlie Brady
2008-01-01  8:10   ` Rehan Khan

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=loom.20071223T025203-262@post.gmane.org \
    --to=rehan.khan@dsl.pipex.com \
    --cc=supervision@list.skarnet.org \
    /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).