Off the top of my head an easy solution in perp that requires no
special or supplemental scripting, flagfile tricks, etc.
For multiple service instances of /usr/bin/myserv -- named myserv00,
myserv01, myserv01, ..., myservNN -- deploy the following set of
service definitions.
First, basic myserv00 runscript (in /etc/perp/myserv00/rc.main):
#!/bin/sh
exec 2>&1
TARGET=$1
SVNAME=$2
start() {
echo "starting ${SVNAME}..."
exec /usr/bin/myserv
}
reset() {
echo "resetting ${SVNAME}..."
exit 0
}
eval ${TARGET} "$_at_"
### eof
Next myserv01 runscript (in /etc/perp/myserv01/rc.main), showing just
the start() stanza for brevity:
...
start() {
if ! perpok -u3 myserv00 ; then
echo "${SVNAME}: not yet running myserv00"
exit 1
fi
echo "starting ${SVNAME}..."
exec /usr/bin/myserv
}
...
Next myserv02 runscript (in /etc/perp/myserv02/rc.main), again the
start() stanza:
...
start() {
if ! perpok -u3 myserv01 ; then
echo "${SVNAME}: not yet running myserv01"
exit 1
fi
echo "starting ${SVNAME}..."
exec /usr/bin/myserv
}
...
And so forth, each instance of myservXX using perpok(8) to check if the
previous instance is up and running before loading current instance.
Many permutations of this basic theme are possible and can be fine tuned
to match your local installation, eg:
* Subsequent instances of myserv may all use myserv00 as the base
instance, and modify/increment -u secs parameter to perpok(8)
accordingly.
* Multiple instances of myservNN may be grouped that use the same
previous instance with the same -u secs parameter to perpok(8), to
permit asynchronous startup of a few at a time, rather than one at a
time as shown above.
See also runtools such as runargs(8) that may allow you to setup your
runscripts with a basic template, loading the perpok(8) parameters from
an external file.
Wayne
http://b0llix.net/perp/
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.
Received on Sun Jun 07 2015 - 00:44:42 UTC