On Thu, Aug 07, 2014 at 11:39:08AM +0200, Jan Pobrislo wrote: > On Fri, 1 Aug 2014 05:32:16 +0000 > Gerrit Pape <p...@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.