The tail end reads: detaching with SIGCKILL on 25593 detaching with SIGCKILL on 25595 detaching with SIGCKILL on 25597 AFTER PTRACE_DETACH/SIGKILL | Parent | Child | Child | Child | Name | reparent | | | | State | R (running) | | | | SleepAVG | 98% | | | | Tgid | 25591 | | | | Pid | 25591 | | | | PPid | 24088 | | | | TracerPid | 0 | | | | FDSize | 256 | | | | ... waiting for completion waitpid(-1, ...): No child processes kill failure $ echo $? which suggests that the test ran ok, but there's a race with the final kill?
Not that I'm any great expert, but what I don't understand is how the child procs can be exiting without leaving a signal for the waitpid to get. Inserting usleep()s in the t/c synchronises things a bit, but the detach/kill takes child procs straight from stopped to gone w/o any intermediate wait/zombie state and without delivering a SIGKILL for the waitpid to catch.
(In reply to comment #1) > Not that I'm any great expert, but what I don't understand is how the child > procs can be exiting without leaving a signal for the waitpid to get. Inserting > usleep()s in the t/c synchronises things a bit, but the detach/kill takes child > procs straight from stopped to gone w/o any intermediate wait/zombie state and > without delivering a SIGKILL for the waitpid to catch. That is correct. When a child's parent exits, the child gets re-parented to process 1, a re-parented process is called a daemon. When the child exits Process 1, as the new parent, then gets the child's waitpid status.
+2006-11-14 Andrew Cagney <cagney@redhat.com> + + * frysk3381/reparent.c (main): Permit ECHILD waitpid status. +
Fix committed.