Messages in this thread | | | From | (Peter Benie) | Subject | Re: Possible bug in wait4(), 2.1.126-129 ? | Date | Mon, 23 Nov 1998 22:20:17 +0000 |
| |
Ion Badulescu writes ("Re: Possible bug in wait4(), 2.1.126-129 ?"): > > 4. the program *must* be run from cron, doesn't matter which user. >[snip] > > wait4: No child processes
The different behaviour comes from cron, not the kernel. Have a look at /proc/self/status for a process run from cron. On a libc5, 2.0.35 system running vixie-cron 3.0.1, I found: SigIgn: 80000000 On a libc6, 2.1.125 system running vixie-cron 3.0.1, I found: SigIgn: 0000000000010000 ^ Ignoring SIGCHLD causes automatic child reaping.
The difference comes from vixie-cron-3.0.1/do_command.c:
#ifdef USE_SIGCHLD /* our parent is watching for our death by catching SIGCHLD. we * do not care to watch for our children's deaths this way -- we * use wait() explictly. so we have to disable the signal (which * was inherited from the parent). */ (void) signal(SIGCHLD, SIG_IGN); #else /* on system-V systems, we are ignoring SIGCLD. we have to stop * ignoring it now or the wait() in cron_pclose() won't work. * because of this, we have to wait() for our children here, as well. */ (void) signal(SIGCLD, SIG_DFL); #endif /*BSD*/
I suspect the difference is in the way that the configure script interacted with the libc. In the USE_SIGCHLD case, you need signal(SIGCLD, SIG_DFL) below the vfork to reset the signal handling for the grandchild process.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |