Configuration services

Configuration services

[David Miller]

Hi, does anyone use services that just set up some things but don't actually run a daemon?  This is hinted at http://smarden.org/pape/djb/daemontools/noinit.html.

Solaris does things like this with their SMF system and what they call "checkpoints".

I am doing this with runit by putting a while ./check; do; sleep 300; done; loop in the run script. Is there a better way?

-- 
David Miller dave@frop.net http://dave.frop.net/

Re: Configuration services

[Laurent Bercot]

> Hi, does anyone use services that just set up some things but don't actually run a daemon?  This is hinted at http://smarden.org/pape/djb/daemontools/noinit.html.
> 
> Solaris does things like this with their SMF system and what they call "checkpoints".
> 
> I am doing this with runit by putting a while ./check; do; sleep 300; done; loop in the run script. Is there a better way?

 You can get rid of the shell for the 5 minutes of sleeping by letting
runit perform the loop itself. Your run script could look like:

#!/bin/sh
./check
exec sleep 300

or even better:

#!/command/execlineb -P
foreground { ./check }
sleep 300

 When sleep exits, the run script terminates, and runsv will automatically
start it again. No need for a loop inside your script. No need to keep the
shell around while the only thing to do is sleep.
 Additionally, you can decide to perform a ./check *now*, by sending a
SIGTERM to the service. (sv term)

 Bear in mind that all this is valid because you actually want to perform
an action regularly, which fits into the "service" model. (But if you are
using a crontab-like service on your system, you could also run your
regular check as a cron job or equivalent, and spare a service.)
 If you just want to set up some stuff *once*, and run no daemon, the
service model doesn't apply; write a script that does what you want and
just call it when needed (for instance at one-time system initialization),
don't try to keep it supervised.

-- 
 Laurent

Re: Configuration services

[Charlie Brady]

On Sun, 26 Jul 2009, Laurent Bercot wrote:

> If you just want to set up some stuff *once*, and run no daemon, the
> service model doesn't apply; write a script that does what you want and
> just call it when needed (for instance at one-time system initialization),
> don't try to keep it supervised.

Keeping it supervised does have the advantage of giving a guaranteed 
consistent environment. However you could provide the same guarantee other 
ways.

Re: Configuration services

[David Miller]

Charlie spoke thusly:
> 
> On Sun, 26 Jul 2009, Laurent Bercot wrote:
> 
> >If you just want to set up some stuff *once*, and run no daemon, the
> >service model doesn't apply; write a script that does what you want and
> >just call it when needed (for instance at one-time system initialization),
> >don't try to keep it supervised.
> 
> Keeping it supervised does have the advantage of giving a guaranteed 
> consistent environment. However you could provide the same guarantee other 
> ways.

The main reason I am attracted to this is it allows me to do dependencies. The example on Gerrits page talks about thinking about eth0 as a service. 

What I am doing is configuring a virtual bridge and some tap devices before I start some other services that need the bridge to be up.

in ./run I configure the bridge and then sleep until ./check fails.  It does seem unnecessary to leave a shell script runnning like that, but it works.

-- 
David Miller dave@frop.net http://dave.frop.net/

Re: Configuration services

[Thomas Schwinge]

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

Hello!

On Sun, Jul 26, 2009 at 11:22:04AM -0500, David Miller wrote:
> Hi, does anyone use services that just set up some things but don't
> actually run a daemon?  This is hinted at
> http://smarden.org/pape/djb/daemontools/noinit.html.

Perhaps I'm misunderstanding, but wouldn't it work to simply use the sv
interface to take the service down once it has done its one-time work?


Regards,
 Thomas

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

Re: Configuration services

[David Miller]

Thomas spoke thusly:
> Hello!
> 
> On Sun, Jul 26, 2009 at 11:22:04AM -0500, David Miller wrote:
> > Hi, does anyone use services that just set up some things but don't
> > actually run a daemon?  This is hinted at
> > http://smarden.org/pape/djb/daemontools/noinit.html.
> 
> Perhaps I'm misunderstanding, but wouldn't it work to simply use the sv
> interface to take the service down once it has done its one-time work?
> 
> 
> Regards,
>  Thomas

I want to be able to have other services depend on it. I don't think that I would be able to use 'sv check' in those dependant service run scripts if the config service has already exited.

I also have a ./finish script that undoes all the configuration, so I don't want ./finish to run unless I really want my "service" to be down.  From reading the sv man page it seems like./finish would get run if I brought up my "service" with sv once.


-- 
David Miller dave@frop.net http://dave.frop.net/

Re: Configuration services

[Laurent Bercot]

> I want to be able to have other services depend on it.
> (cut)
> I also have a ./finish script that undoes all the configuration

 ... and if a stray signal happens to kill your shell, your "service"
will be deconfigured and reconfigured.
 The supervisor is there to ensure a process remains up no matter what;
it's suppoed to maintain a *process*, not a *state*. The only state it
can guarantee is 'want up', i.e. if the process ever goes down, you can
be sure it will be run again.

 You are not the first to want to use the daemontools/runit pattern as
a dependency manager, implementing a wider notion of 'service' than it
really does. As far as I can tell, this is not a very good idea - it
can be made to work, but it's generally shaky and unsatisfying. As a
rule of thumb, whenever you have a loop in your run script, you are
probably abusing the pattern.

 The supervision tree that svscan/supervise or runsvdir/runsv gives
you is a *process* tree; and the whole system is about supervising
*processes*. DJB started naming 'services' the supervised processes
because most services can be implemented via a run script setting up
some environment and executing into a daemon; but it's obvious that
people have a wider definition of 'service'. For instance, keeping
a net interface up should legitimately be called a service, but most
Unix implementations do not need a process that runs constantly to
achieve that; and *adding* a process to be controlled by a supervisor
to emulate a down/up service state is resource-consuming (even if
it's as light as a "sleep" binary) and should not be needed. It's
trying to fit a square peg into a round hole.

 Don't misunderstand me, I'm a fervent advocate of daemontools/runit,
and I believe it's a wonderful pattern, a necessary basis of any
reliable Unix implementation, and a very sound *fundation* for a
dependency management system. But per se, it's not a dependency
management system: it's a process management system. What we need
is another piece of software, using the supervision tree as an
underlying layer, that does proper dependency management and handles
a wider notion of 'service' than daemontools/runit.

 As far as I know, such a piece of software still remains to be written.
In the meantime, you can certainly use daemontools/runit as a service
dependency manager, but there *will* be holes and awkwardnesses in your
system, and you're going to have to consume extra resources to make it
work.

-- 
 Laurent

Re: Configuration services

[David Miller]

Laurent spoke thusly:
> > I want to be able to have other services depend on it.
> > (cut)
> > I also have a ./finish script that undoes all the configuration
> 
>  ... and if a stray signal happens to kill your shell, your "service"
> will be deconfigured and reconfigured.
>  The supervisor is there to ensure a process remains up no matter what;
> it's suppoed to maintain a *process*, not a *state*. The only state it
> can guarantee is 'want up', i.e. if the process ever goes down, you can
> be sure it will be run again.
> 
>  You are not the first to want to use the daemontools/runit pattern as
> a dependency manager, implementing a wider notion of 'service' than it
> really does. As far as I can tell, this is not a very good idea - it
> can be made to work, but it's generally shaky and unsatisfying. As a
> rule of thumb, whenever you have a loop in your run script, you are
> probably abusing the pattern.

Thanks for the good post.  It does seem like I am fitting a square peg in a round hole, so I wanted to make sure that I was not missing something.  And apparently I am not.  A few pages on Gerrit's site made me think that runit could be used in this way.  Quoting Gerrit from http://smarden.org/pape/djb/daemontools/noinit.html :

"Having the above design in mind, why not think about eth0 as a service? Let a supervisor garantee the state of eth0, take it like any other service."

I wonder if Gerrit can clarify what he meant by that.

runit already has some notion of states as opposed to processes,  it can use a ./check script to decide whether a service is "ready". I guess my point is that runit is very close to being able to be used in this manner but as you say it is a bit akward.

I am considering writing a shell script I can call from dependent services instead of using 'sv check'. But I am not sure if my while loop is sufficiently abominable to necessitate the effort. 

Thanks for the input everyone!
-- 
David Miller dave@frop.net http://dave.frop.net/