Messages in this thread | | | Date | Fri, 13 Aug 2004 16:50:57 -0600 (MDT) | From | Torin Ford <> | Subject | Re: 2.6.x Fork Problem? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |