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: Fri, 11 Oct 2013 18:33:32 +0200
- 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>
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?