Re: [PATCH/RFC] Re: logpipe error handling patch

From: Gerrit Pape <pape_at_smarden.org>
Date: Fri, 8 Aug 2014 08:20:16 +0000

On Thu, Aug 07, 2014 at 11:39:08AM +0200, Jan Pobrislo wrote:
> On Fri, 1 Aug 2014 05:32:16 +0000
> Gerrit Pape <pape_at_smarden.org> wrote:
> > On Wed, Jul 30, 2014 at 03:01:16PM +0200, Jan Pobrislo wrote:
> > > I was under the assumption that the pipe is left open so you can
> > > send signals in case the supervised processes have trouble exiting
> > > the normal way.
> >
> > The service stopped already in this situation, I'm with Laurent in
> > this case. But not the log service, so its control pipe should stay
> > open and commands processed.
>
> Can't it happen the other way around? (log/run exiting and ./run
> being stalled) I didn't dig too deep into runsv code to see if that case
> is handled differently.

This is about runsv behavior when receiving the x command through the
control interface, which only is supported for the main service, not the
log service. So, no.

> > What do you think about this patch?:
> >
> >
> > When runsv is told to exit, it now no longer processes any control
> > characters read from the control pipe (it still does for the log
> > service). It waits until the log service has terminated and then
> > exits. The sv program now properly reports this through the
> > status command.
>
> Using sv with runsv in "wait" state:
> * Will I still be able to see PIDs of the processes until they exit?
> * Will I be able to send signals to them using sv kill etc. or will I
> have to extract the PIDs and kill them manually?

In the wait state, the service is down, so there's no pid. For the
appendant log service you still can use all the functionality of sv.

> * How this interacts with the control scripts?

Nothing should change in this regard.

The devground branch in my git repository has a slightly revised version
of the patch. I'd be happy to receive feedback, there might still be
some glitches.

Regards, Gerrit.
Received on Fri Aug 08 2014 - 08:20:16 UTC