This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] test-skeleton: Kill any child process's offspring
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 10 Feb 2014 18:17:09 +0100
- Subject: Re: [PATCH] test-skeleton: Kill any child process's offspring
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 1 dot 10 dot 1309231748080 dot 4379 at tp dot orcam dot me dot uk> <20131011163332 dot GA20086 at domone dot podge>
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?