This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] test-skeleton: Kill any child process's offspring


friendly ping
On Fri, Oct 11, 2013 at 06:33:32PM +0200, OndÅej BÃlka wrote:
> On Mon, Sep 23, 2013 at 09:24:36PM +0100, Maciej W. Rozycki wrote:
> > Hi,
> > 
> >  Some of the test cases driven by our test-skeleton create subprocesses.  
> > In a test scenario involving what looks to me like a Linux kernel bug I 
> > have observed stray processes of this kind left behind where their parent 
> > was killed by test-skeleton after a timeout however the process in 
> > question was not.  This leads to a clutter in the environment our test 
> > suite is run within and on weaker systems may also affect test results 
> > where the processing power consumed by such a leftover causes the lack of 
> > same for subsequent test cases and consequently timeouts.
> > 
> >  The cause of leaving such processes behind is signal_handler that calls 
> > kill to send SIGKILL to test-skeleton's immediate child only and not any 
> > further descendants.  Conveniently as the child starts it places itself in 
> > a separate process group that is then inherited by any further children.  
> > Therefore a simple if not obvious fix to this problem is to send SIGKILL 
> > to the child's process group instead which this change implements.  There 
> > is no need to wait for any additional descendants left as the exit status 
> > of the immediate child is enough for our purposes and init(8) will take 
> > care of the rest in the unlikely case this change addresses.
> > 
> >  The problem itself was observed with nptl/tst-mutexpi9 and that this fix 
> > makes go away -- no stray processes after the test suite has terminated 
> > anymore (nptl/tst-mutexpi9 has its own problem of course on this target, 
> > but that's another matter; I think there's a value in making the test 
> > suite itself more robust).
> > 
> >  OK to apply?
> > 
> What is status of this patch?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]