Re: staggering runsv startup

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

On Thu, 04 Jun 2015 13:41:12 -0700
Jameson Graef Rollins <jrollins_at_finestructure.net> 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.

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
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