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

[Dean Hall <deanpence@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lars Kellogg-Stedman wrote:
> I was mulling over service dependencies yesterday, and I wonder if it would
> make sense to add a "setup" phase to runsv's service startup sequence.
> This would allow, for example, svwaitup to block while a service performed
> one time initialization.

Although I think runit itself should remain pristine in that it only
runs the ./run script for a service, I'm working on a system
initialization scheme that factors something just like this in. See my
initial draft of the scheme at
<http://sourceforge.net/projects/sysinit>; please note that it has
changed significantly since the first reference release.

In particular, what the relevant part of sysinit does is create an
infrastructure for resolving both runit-managed and arbitrary
dependencies that does not depend on svwaitup (whose ability to resolve
dependencies is fundamentally flawed).

Basically, in its current incarnation, sysinit takes the following steps
in ./run:

1) It optionally checks a configurable directory for a series of
dependencies. A dependency, in this case, is a file in that directory.
If the file is a directory (or symlink to one), it is expected to be a
runit-managed service; if it is running (using a method described
below), the dependency is considered resolved. If the file is an
executable file (or a symlink to one), it is run; if it returns 0, the
dependency is considered resolved. (That is the part that I think could
solve your initialization question.) If any dependency fails, the
service initialization is abandoned and can optionally stop the service
or simply exit (and allow runit to try again) after an optional delay.

2) If all dependencies resolve, sysinit creates a lockfile for the
service (separate from runit's) and starts it. (This is how service
dependencies are resolved. Thus, a service is not considered started
until all its dependencies are resolved and the service proper is
actually running. This does not solve more fundamental race
conditions--such as when a service starts but immediately fails, and
another service checks its dependency in the short time in which the
service is running--but I don't think those are solvable in any
straightforward fashion, and I'm not sure if they should, as such race
conditions indicate very severe problems that usually require human
intervention.)

If anyone wants to talk to me about this privately, feel free to email
me here. Or we can talk about it on the list if it's okay with Gerrit.
I'm open to suggestions about how I can improve my system, and I'd be
glad to email out the new implementation (in progress) for inspection
and suggestions.


Dean

> Here I'm thinking particularly of long-running setup actions, such as
> database initialization or something.  The current solution -- waiting for
> a number of seconds and then crossing our fingers -- doesn't provide the
> level of control that runit provides in other areas.
> 
> This would make the start sequence look like this:
> 
>   IF file "setup" exists THEN
>     SET STATE TO S_SETUP
>     RUN file "setup"
>   END IF
> 
>   SET STATE TO S_RUN
>   RUN file "run"
> 
>   IF file "finish" exists THEN
>     SET STATE TO S_FINISH
>     RUN file "finish"
>   END IF
> 
> svwaitup() would block if a service was in the "setup" phase.  This should
> require only minor changes to runit -- introduce "runsv" to the "setup"
> script, and modify svwaitup, svwaitdown, and runsvstat to understand a new
> state value in the status file.
> 
> -- Lars
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCGrBIY5YOge8zySQRAl4YAKCAm5FlsWNOhFZL8EerqkytmOU7fACdHZ+9
To6fK4MQbN/QQzWTvGRNmhc=
=sBSs
-----END PGP SIGNATURE-----