* runsvdir under runsv
@ 2007-10-10 13:16 Lasse Kliemann
2007-10-10 19:42 ` Joan Picanyol i Puig
0 siblings, 1 reply; 5+ messages in thread
From: Lasse Kliemann @ 2007-10-10 13:16 UTC (permalink / raw)
To: supervision
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: runsvdir under runsv
2007-10-10 13:16 runsvdir under runsv Lasse Kliemann
@ 2007-10-10 19:42 ` Joan Picanyol i Puig
2007-10-10 21:47 ` Lasse Kliemann
0 siblings, 1 reply; 5+ messages in thread
From: Joan Picanyol i Puig @ 2007-10-10 19:42 UTC (permalink / raw)
To: supervision
* 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: runsvdir under runsv
2007-10-10 19:42 ` Joan Picanyol i Puig
@ 2007-10-10 21:47 ` Lasse Kliemann
2007-10-11 12:50 ` Gerrit Pape
0 siblings, 1 reply; 5+ messages in thread
From: Lasse Kliemann @ 2007-10-10 21:47 UTC (permalink / raw)
To: supervision
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: runsvdir under runsv
2007-10-10 21:47 ` Lasse Kliemann
@ 2007-10-11 12:50 ` Gerrit Pape
2007-10-11 16:06 ` Lasse Kliemann
0 siblings, 1 reply; 5+ messages in thread
From: Gerrit Pape @ 2007-10-11 12:50 UTC (permalink / raw)
To: supervision
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: runsvdir under runsv
2007-10-11 12:50 ` Gerrit Pape
@ 2007-10-11 16:06 ` Lasse Kliemann
0 siblings, 0 replies; 5+ messages in thread
From: Lasse Kliemann @ 2007-10-11 16:06 UTC (permalink / raw)
To: supervision
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-10-11 16:06 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-10 13:16 runsvdir under runsv Lasse Kliemann
2007-10-10 19:42 ` Joan Picanyol i Puig
2007-10-10 21:47 ` Lasse Kliemann
2007-10-11 12:50 ` Gerrit Pape
2007-10-11 16:06 ` Lasse Kliemann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).