Defining the workgroup objectives

Gerrit Pape pape at
Sun Jul 31 19:20:20 UTC 2005

On Sun, Jul 31, 2005 at 08:07:46PM +0200, a-aa wrote:
> Gerrit Pape wrote:
> >This is inconsistent: if "hald" fails, then you have a way of knowing
> >whether it's ready; it's not ready because "hald" fails.  Find out why
> >"hald" fails and use this check to test whether it's ready.  This seems
> >to be a special case you describe, can well be handled with runit's 
> >dependency concept though.
> >
> I can't remember right now what other things I've seen do this, but it
> has happened, and my testbox has only a fairly small amount of basic
> packages.  How would you handle this "cleanly" in runit?
> >Waiting for dbus to detach isn't a reliable solution, maybe for system
> >startup, but not for the system's uptime: dbus could terminate
> >immediately after fork and exec; or it could terminate any time later,
> >causing "hold" also to fail later.  You can handle this when running the
> >daemons under a parent.
> >  
> Of course, but it's not our job to make sure a daemon runs for 3 hours,
> it's our job to start it, and only start things depending on it when
> it's properly started.

Well, I don't think so.  init is not just about starting up services in
a specific order; it's also about stopping services, starting up
services while uptime (think package installation), controlling services
(such as restart or signals), and taking services down at system
shutdown.  Doing all this, it's just a small step to also supervise
service daemons, and detect unintended shutdown (eg. crashes).

runit defines the state of a service, not just the startup.  A service
defined to be up will be started at boot-time, and, while uptime, will 
be restarted if it terminates, as long as it is defined to be up.  Of
course there also are other states.

A good dependency concept not only finds out the right order to startup
services, but also to shut them down.  A real good dependency system
takes service dependencies also into account when a single service is
taken down (think removing packages) or terminates unintentionally while
system uptime.

Regarding your question above, this would be handled automatically by
runit, as it will restart the "hold" service if it fails, until it
succeeds eventually.  If you don't think that's a "clean" solution, or
the startup of this specific service takes a lot of resources, add a
check for the dependency to the top of the run script (before execing
into the daemon), and either wait, or simply exit to be restarted.  This
also works with cross-machine dependencies, btw.

System startup is just a minor part of init's duties in my opinion.

Regards, Gerrit.
Open projects at

More information about the initscripts-ng-devel mailing list