Bug 3502

Summary: tests/frysk3381 fails on FC-5.18
Product: frysk Reporter: Andrew Cagney <cagney>
Component: generalAssignee: Andrew Cagney <cagney>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Bug Depends on:    
Bug Blocks: 2104, 3381    

Description Andrew Cagney 2006-11-10 18:07:07 UTC
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?
Comment 1 Chris Moller 2006-11-10 18:56:55 UTC
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.
Comment 2 Andrew Cagney 2006-11-10 19:14:35 UTC
(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.
Comment 3 Andrew Cagney 2006-11-14 16:33:23 UTC
+2006-11-14  Andrew Cagney  <cagney@redhat.com>
+
+       * frysk3381/reparent.c (main): Permit ECHILD waitpid status.
+
Comment 4 Andrew Cagney 2006-11-14 16:34:08 UTC
Fix committed.