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

[Gerrit Pape <pape@smarden.org>]

On Mon, Feb 21, 2005 at 05:41:59PM +0000, 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.
> 
> 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.

Yes, true.  I don't consider svwaitup as the current solution, but as a
workaround.  The fix actually should be in the service daemons I think,
see http://smarden.org/runit/dependencies.html

> This would make the start sequence look like this:
[...]
> 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.

This doesn't eliminate the race condition, just lets it look a bit
better.

I'm still looking for examples why service dependencies, more than runit
currently provides, is needed.  What are these services that must be
started not before another service has been started and is available,
and that don't recognize the error if the service depended upon isn't
available?  How do these services behave on that error condition?,
shouldn't they log the error and fail?

What are these services that need to be taken down manually after a
service they depend upon became down?  How do they behave if a service
they need has been available on startup, but disappears while uptime?,
shouldn't they log the error and fail, or maybe retry?

What other problems are service dependencies meant to solve?

I'm aware of one example, the problem that service daemons that log
through syslog cannot know whether the syslog service is enabled, simply
because the corresponding unix functions return void.  To work around
this for services that cannot switch to the runit logging facility, I
added the socklog-check program to the socklog package.  This program
checks for a listener on (e.g.) /dev/log, and fails if the socket isn't
maintained; it can be added to the top of the run script with set -e or
as `socklog-check unix /dev/log || exit 1` to prevent the service from
being started in this case.

Thanks, Gerrit.