Re: 2.6.x Fork Problem?

[Frank van Maarseveen <frankvm@xs4all.nl>]

On Fri, Aug 13, 2004 at 03:36:34PM -0400, Richard B. Johnson wrote:
> 
> In the above code there is something missing. in the code shown,
> the child __will__ wait in exit() until somebody claims its status.
> However, the child probably did a setsid(), becoming a process-leader
> or the parent set up a SIGCHLD handler before the fork. In these
> cases, the exit() will quickly exit because somebody will claim
> the exit status.
> 
> So, by the time the parent gets the CPU, the child is long gone.
> The solution is to use the default SIGCHLD handler if the parent
> expects to get the child's status and for the child to not execute
> setsid(), which will allow init to reap its status.

AFAIK a child doing setsid() has no effect whatsoever on any wait*()
done by the parent. It just sets a new session leader.

But SIGCHLD set to SIG_IGN instead of SIG_DFL is a perfect explanation.
Rereading alan's reply I suddenly got it: "random status" didn't refer
to the &status arg but to the signal status. SIG_IGN is inherited I
guess so a

	signal(SIGCHLD, SIG_DFL);

once before the fork() should fix it. Hmm, so actually our parent should
have reset SIGCHLD before exec'ing this code. This could cause more
problems.

-- 
Frank