Re: 2.6.x Fork Problem?

[Torin Ford]

On Fri, 13 Aug 2004, Frank van Maarseveen wrote:

> 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.
> 
> 

Thanks to everyone for their responses.  Alan and others were correct in 
that we needed to change the signal handler for SIGCHLD.  If I remember 
correctly, apache changes the signal handler for SIGCHLD, so we would have 
inherited those signal handlers from apache.  Adding a signal(SIGCHLD, 
SIG_DFL) before the fork fixed the problem for us.

Torin Ford
Venturi Technology Partners
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/