Defining the workgroup objectives

Mike Bell debian-init at mikebell.org
Mon Aug 8 18:00:11 UTC 2005


On Mon, Aug 08, 2005 at 06:46:53PM +0200, Sven Mueller wrote:
> So runit doesn't implement dependencies, only the run scripts do.

I can see how the idea of having some programmatic view of dependencies
is appealing, but the problem is that you can't just say "X depends on Y
being up" and be done with it, because how do you define "up" for Y?
There isn't really a good way except for testing with a daemon-specific
bit of shell scripting, which is one of Gerrit's main points.

Now if you really need the ability to see the dependencies of a
particular service in a more obvious manner (for instance a GUI program
that can show you a graph of services and their dependencies) one thing
that might work is to have a short shell script whose job it is to test
if the daemon is up, one for every service. Then runit could make use of
those and dependency information (most likely in the form of symlinks)
to perform the same job that the run script checking does now, but a)
also provide a programmatically parsable view of dependencies and b)
avoid so much code-duplication in the shell scripts. It could also be
used to provide the user with a more accurate view of the state of
his/her services, confirming that the daemon which is "up" is really up.

Basically, every service would aquire an executable file (test_if_up?)
and a directory (dependencies) which would most likely be full of
symlinks to other services.

One might want to add a second directory in order to separate services
which must be up before starting my daemon from services which should be
taken down if my daemon goes down, since they don't necessarily overlap
completely, and also since you'd otherwise have to do freaky
traverse-the-whole-tree stuff in order to find out who depends on you.

The other failing of this idea is that there is only one test_if_up for
each service. But I can't really envision a service where several
individual tests, one per daemon, works but a single test script cannot
be made to.



More information about the initscripts-ng-devel mailing list