runsvdir under runsv

runsvdir under runsv

[Lasse Kliemann]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

I'd like to run a bunch of services in a kind of sub-hierarchy under 
`/service/sub'; more precisely the service in `/service/sub' shall be something 
like runsvdir managing services in a directory `/service/sub/service'.

The naive approach was to let `/service/sub/run' be like this:

   #!/bin/sh
   exec runsvdir service

One problem with this is that bringing down all services in 
`/service/sub/services' involves something like

   sv o /service/sub ; sv h /service/sub

meaning that a simple removal of `/service/sub' is not enough, for this only 
will essentially result in a `sv x /service/sub' (according to the 
documentation of runit). As a solution, I came up with putting

   #!/bin/sh
   sv h .

into `control/t'. It seems to work, but I am not sure whether this is a good 
solution, in particular whether it is free of race-conditions.

Comments are welcome.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: runsvdir under runsv

[Joan Picanyol i Puig]

* Lasse Kliemann <lasse-list-supervision-2007@plastictree.net> [20071010 14:57]:
> I'd like to run a bunch of services in a kind of sub-hierarchy under 
> `/service/sub'; more precisely the service in `/service/sub' shall be something 
> like runsvdir managing services in a directory `/service/sub/service'.
> 
> The naive approach was to let `/service/sub/run' be like this:
> 
>    #!/bin/sh
>    exec runsvdir service
> 
> One problem with this is that bringing down all services in 
> `/service/sub/services' involves something like
> 
>    sv o /service/sub ; sv h /service/sub

What's wrong with 'sv h /service/sub/services/*' ?

http://cr.yp.to/daemontools/svscan.html
"svscan is designed to run forever."

The same applies to runsvdir; if you need to stop it, you are doing
something wrong.

qvb
--
pica

Re: runsvdir under runsv

[Lasse Kliemann]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

* Joan Picanyol i Puig writes:
> * Lasse Kliemann <lasse-list-supervision-2007@plastictree.net> [20071010 14:57]:
> > I'd like to run a bunch of services in a kind of sub-hierarchy under 
> > `/service/sub'; more precisely the service in `/service/sub' shall be something 
> > like runsvdir managing services in a directory `/service/sub/service'.
> > 
> > The naive approach was to let `/service/sub/run' be like this:
> > 
> >    #!/bin/sh
> >    exec runsvdir service
> > 
> > One problem with this is that bringing down all services in 
> > `/service/sub/services' involves something like
> > 
> >    sv o /service/sub ; sv h /service/sub
> 
> What's wrong with 'sv h /service/sub/services/*' ?
 
Howsoever, neither of the two solutions yields an elegant way to make this 
work *inductively* starting from the 'root' runsvdir process in /service.

Well, one could place

   sv x ./service/*

in /service/sub/finish.

> http://cr.yp.to/daemontools/svscan.html
> "svscan is designed to run forever."
>
> The same applies to runsvdir; if you need to stop it, you are doing
> something wrong.

Can this reasonably be applied to any runsvdir (or svscan) process other than 
the 'root' one?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: runsvdir under runsv

[Gerrit Pape]

On Wed, Oct 10, 2007 at 11:47:12PM +0200, Lasse Kliemann wrote:
> Well, one could place
> 
>    sv x ./service/*
> 
> in /service/sub/finish.

That's what I'd suggest, anything wrong with it?

Regards, Gerrit.

Re: runsvdir under runsv

[Lasse Kliemann]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

* Gerrit Pape writes:
> On Wed, Oct 10, 2007 at 11:47:12PM +0200, Lasse Kliemann wrote:
> > Well, one could place
> > 
> >    sv x ./service/*
> > 
> > in /service/sub/finish.
> 
> That's what I'd suggest, anything wrong with it?

Maybe it has got a drawback compared to the solution of sending a HUP to the 
runsvdir process (acting on /service/sub/service). Assume this process is 
terminate (by TERM, not HUP), and in the meantime until the finish script 
runs, a directory from /service/sub/service is removed. Then the runsv 
process of that directory will not be terminated.

In other words: runsvdir (by its internal list of all PIDs managed) has a 
better chance for terminating all runsv processes in /service/sub/service 
than a shell script acting based on filenames in /service/sub/service only. 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]