Re: How to kill runsv, no matter what?

["Daniel Clark" <dclark@pobox.com>]

On 2/23/07, Gerrit Pape <pape@smarden.org> wrote:
> On Thu, Feb 22, 2007 at 10:51:50PM -0500, Daniel Clark wrote:
> > I made a simple test case that should make this bug (or my error in
> > using the software) easy to reproduce. I'm attaching it since it is so
> > tiny; it is also available from
> > http://opensysadmin.com/bugs/runit/test1-service.tar.bz2
> >
> When asked to exit, the runsv supervisor makes sure that all logs are
> written to the log service before terminating; it first sends TERM to
> the main service, then waits for it to terminate, and finally waits for
> the log service to terminate, before runsv exits itself.
>
> In the case of your example service, the main run script execs into a
> shell script that starts a 'sleep' subprocess.  Now when runsv is told
> to exit, it sends the service (the ./test1-sv.sh shell script) a TERM
> signal, the shell script terminates (fine), but is leaving behind the
> 'sleep' subprocess.  The log service's run script execs into a svlogd
> process, svlogd will terminate as soon as it sees end-of-file on the
> pipe connected to its standard input.  Because there's still the 'sleep'
> subprocess running with its output connected to the pipe, and so to
> svlogd's standard input, svlogd will wait; it might well be that there's
> still data available on the pipe to be written to the logs.  Once the
> 'sleep' subprocess exits, runsv should exit too.

Ah, that makes a lot of sense. However I'm not seeing how this
behavior can mesh with package management systems. e.g.:

(a) I install an "runit" package, which starts up a runsvdir process
(b) I link some services into my runscvdir /var/service directory; I
can't really control if those processes start child processes in many
cases; let's say there is a service like my example service among the
services (in practice, I'm guessing there is probably some way I can
get my shell script to capture TERM and kill the 'sleep' process
before exiting itself)
(d) I remove the "runit" package. Since I am no longer going to have
"runit" installed, I think it follows that all "runit" processes, such
as svlogd, need to be gracefully shut down, no matter what their
state.
(e) Runit is removed, but there are some svlogd processes still
around, and therefore also still some files tracking runit state in my
/etc/sv directory
(f) I install Runit again.
(g) I want to re-enable my service, so I again link the service into
my /var/service directory. However since there is still a svlogd
process running (or I killed it manually), there is still lingering
state information in /etc/sv, so runit is confused and complains.

So I guess my question is, is there any way to handle the
install-remove-install case cleanly with runit?

In practice this may not be an issue, but I'm running into it all the
time in testing. The previously running svlogd causes failure in 2
ways: (a) the state in /etc/sv/servicename confuses runit, and (b) it
wants to write to the same log file as any new svlogd daemons that
start up.

Actually, wouldn't this also be a problem if I just wanted to
force-restart a service that spawns child processes? If the service is
restarted but the old logging daemon doesn't get force-killed, don't I
run into the same situation as with the install-remove-install (2
conflicting svlogd processes)?

Thanks,
-- 
Daniel Clark # http://dclark.us # http://opensysadmin.com