Re: Adding a 'setup' phase to service startup?

[Dean Hall <deanpence@gmail.com>]

Lars Kellogg-Stedman wrote:
>>Although I think runit itself should remain pristine in that it only
>>runs the ./run script for a service...
> 
> 
> And the finish script.  And the log/run script.  And the various control/*
> scripts.  My point being, adding a setup phase to the service doesn't
> represent much of a change, especially since it has zero impact on the
> system's behavior if there is no setup script in place.

I agree. One should be able, completely optionally, to implement
whatever dependency resolution scheme one wants--and one can do that
right now. Adding complexity to the runit system is only asking for bugs
and, perhaps more importantly, code that some people may never use.
Runit and its various components all do one thing each, and they do them
well, and, IMO, that's the best you can ask of any software.

> Adding an entire new layer on to handle dependencies would seem to detract
> from the inherent simplicity of the system -- one should be able to use
> runsv, by itself, to start up a service and have behave it exactly like it
> would when run "in production".  This means that new logic for things like
> dependency resolution (or respawn limiting) needs to be either (a)
> implemented in runsv, or (b) implemented as external commands that can be
> executed by the 'run' script.

As for (a), implementing it in runsv, I think runsv does its job well
now. It doesn't need to do anything else. The daemontools/runit spirit
of doing things is to leave room for other tools to do their jobs and
let the user decide how complex they want their scheme to be--and of
course, for various tools to work together, each of them doing only one
thing and doing it well.

I find this more in the spirit of Linux than SysV init or many other
software tools out there, that either do everything conceivable so as
not to leave somebody's obscure desires out in the cold and/or to leave
no options to the user (vixie-cron anyone?).

> Implementing service dependencies in the run script is already difficult,
> particularly because the runit tools are unable to differentiate between
> "starting up" and "up".  This is the small, reasonably well bounded problem
> that I'm hoping to solve.

And this is the problem I think I've solved. To be more specific than
before, I use several different tools written (for now) in BASH:

- sv-isrunning <service_dir>:
This determines if a service is running by trying to lock the lockfile
created by sv-runlock. If it's locked, the service is running. If not,
the service is not running (and may still be checking its own dependencies).
- sv-require <service_dir|executable_path>:
If the argument is a directory, it asserts that the service is running
(using sv-isrunning). If it is the path to an executable file, it runs
it (leaving file security to the user); if it returns 0, the dependency
resolves; otherwise, the dependency doesn't resolve.
- sv-checkdeps <dir>:
This checks the directory for service dependencies and runs sv-require
(optionally as a different user) on each of them, failing itself on the
first failure of sv-require.
- sv-runlock:
This is a djb-chaining script that merely locks a file and execs its
arguments.
- sv-run:
This is a djb-chaining script that checks dependencies (by calling
sv-checkdeps), optionally gets an envdir, and execs run-lock with its
arguments.

I think it's a pretty simple system that follows the spirit of runit,
each piece of the toolkit doing one thing and passing off details to
lower-level tools (when necessary). Also, it does solve the problem
you're talking about.

I've put up a little reference tarball at
<http://sysinit.sourceforge.net/> in case anyone wants to take a gander.


d

> 
> -- Lars
>