James Powell:
If runit had the ability to order processes like OpenRC where you have:
before=
after=
setups, you could order the entire tree structure.
As I might have mentioned before, people have been saying that one could
do that for years; nosh is the existence proof that it can be done,
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 myserv0
On Thu, 4 Jun 2015 17:46:29 -0700
James Powell wrote:
> If runit had the ability to order processes like OpenRC where you
> have:
>
> before=
> after=
>
> setups, you could order the entire tree structure.
>
> The problem with sv check is the command often can only check the
> status of the se
Hi,
On 2015-06-05 at 00:01 CEST
Laurent Bercot wrote:
>On 04/06/2015 22:41, Jameson Graef Rollins wrote:
>> 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 wo
: Steve Litt<mailto:sl...@troubleshooters.com>
Sent: 6/4/2015 3:33 PM
To: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org>
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 man
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
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 supervi
On Thu, 04 Jun 2015 14:44:38 -0700
Jameson Graef Rollins wrote:
> On Thu, Jun 04 2015, Lucy Pseudonym wrote:
> > You can create `down` files in the service dirs as described in [1]
> > and enable the services from a script at boot time.
>
> Hi, Lucy. That's an interesting suggestion. It would
On 04/06/2015 22:41, Jameson Graef Rollins wrote:
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 restar
On Thu, Jun 04 2015, Steve Litt wrote:
> 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
On Thu, Jun 04 2015, Lucy Pseudonym wrote:
> You can create `down` files in the service dirs as described in [1]
> and enable the services from a script at boot time.
Hi, Lucy. That's an interesting suggestion. It would require building
out more/other infrastructure, though, which is something
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
You can create `down` files in the service dirs as described in [1]
and enable the services from a script at boot time.
[1]: http://smarden.org/runit/runsv.8.html
On 4 June 2015 at 22:41, Jameson Graef Rollins
wrote:
> Hi, all. I am using runit to supervise a large set of nearly identical
> pro
13 matches
Mail list logo
