Re: staggering runsv startup

From: Steve Litt <>
Date: Thu, 4 Jun 2015 17:40:21 -0400

On Thu, 04 Jun 2015 13:41:12 -0700
Jameson Graef Rollins <> wrote:

> Hi, all. I am using runit to supervise a large set of nearly
> identical processes. Each process accesses certain IO-bound shared
> resources (e.g. NFS mount) at startup. At system initialization,
> when runsvdir is launched, it launches all these processes (via
> runsv) essentially simultaneously. This causes a big resource
> contention at initialization that occasionally causes problems.
> What I would like is to somehow stagger the startup of the processes,
> to avoid the resource contention. I could do this by putting a random
> sleep into the ./run scripts, but this would also cause random startup
> delays on subsequent process restarts via "sv restart" or the like
> (which we occasionally need to do).
> What I would prefer instead is to add random delays to the startup of
> the *runsv* processes, since this would only apply at system
> initialization. Unfortunately I can't see any way to do that right
> now (other than somehow wrapping the runsv binary itself).
> Does anyone know any way to accomplish what I'm looking for? I don't
> believe runsvdir supports any options that would apply here. Is it
> possible to somehow point runsvdir to a alternate runsv executable to
> which I could add the random delays?
> Any suggestions would be much appreciated. Thanks.
> jamie.

In the 1 script, put "down" files in every directory under /service
except one called "order". Then, the order process is called, and it
erases the down file from one at a time, sleeping 1 second after each.
When all of them have been "undowned", have "order" put a "down" file
in its own directory and stop itself.

The one thing I dislike about daemontools type process managers is you
can't order the processes.


Steve Litt
June 2015 featured book: The Key to Everyday Excellence
Received on Thu Jun 04 2015 - 21:40:21 UTC

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