Re: Possible bug in wait4(), 2.1.126-129 ?
H. J. Lu (hjl@freya.yggdrasil.com)
Mon, 23 Nov 1998 15:03:00 -0800 (PST)
>
> 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.
>
I was told the behavior of
signal(SIGCHLD, SIG_IGN)
is totally undefined under POSIX.
--
H.J. Lu (hjl@gnu.org)
-
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/