RE: staggering runsv startup

From: James Powell <>
Date: Thu, 4 Jun 2015 17:46:29 -0700

If runit had the ability to order processes like OpenRC where you have:


setups, you could order the entire tree structure.

The problem with sv check is the command often can only check the status of the service.

Sent from my Windows Phone
From: Steve Litt<>
Sent: ‎6/‎4/‎2015 3:33 PM
Subject: Re: staggering runsv startup

On Fri, 05 Jun 2015 00:10:05 +0200
Laurent Bercot <> wrote:

> What you really want is a real service manager that works on top
> of a process supervision system and that would managed a complete,
> ordered initialization sequence for you.
> Steve is saying that process supervisors are lacking real service
> management capabilities, and he's right. Process supervision does
> not offer service management; service management is more complex and
> one layer above.

I'm not familiar with the definitions of service managers and process
supervisors, but the simple ability to declare the order of initial,
bootup startup, would go a long way.

I'm not saying such ordering would free me from needing to check for
required other services being ready in this service's run script. I'm
just saying that ordering would eliminate the tendency of such checks
to result in one service coming up per cycle around /service, and would
produce reasonable boot times, because in most cases teh required
services *would* be up and functioning by the time the service that
needs them is started.

> There are some tools to accomplish service management on top of
> process supervision. One that I like is anopa:
> but it's designed to work with s6, not runit.
> I'm also working on a service management system for s6, that should
> hit beta soon.

This is very good news. Ordering is sorely needed in the daemontools
world, and I think your new S6 service management system would be the
first to do that without kludges like I enumerated in other emails.



Steve Litt
June 2015 featured book: The Key to Everyday Excellence
Received on Fri Jun 05 2015 - 00:46:29 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC