> I was told the behavior of
>
> signal(SIGCHLD, SIG_IGN)
>
> is totally undefined under POSIX.
Perhaps.. but it appears that the Linux kernel (and the Solaris kernel as
well) just takes care of the child processes internally if SIGCHLD is set
to SIG_IGN. This apparently translates to calls to sys_wait4() inside the
kernel, from the signal dispatcher I guess, which threw me off for a while
when I tried to debug the kernel..
It's crond's fault for setting unexpected values for signal handlers
before executing the jobs. rh52 has it fixed indeed, but they ought to
make a fixed cron rpm available through the updates directory.
Anyway, thanks to all those who responded. It looks like everyone had a
revelation at the same time :-), when I got the first message about cron
being at fault I was just searching through Solaris man pages for execve's
behavior with respect to signal handlers. Linux man pages are completely
lacking in that respect, btw..
exec(2)
Signals that are being caught by the calling process are set
to the default disposition in the new process image (see
signal(3C)). Otherwise, the new process image inherits the
signal dispositions of the calling process.
signal(3C)
If any of the above functions are used to set SIGCHLD's dis
position to SIG_IGN, the calling process's child processes
will not create zombie processes when they terminate (see
exit(2)). If the calling process subsequently waits for its
children, it blocks until all of its children terminate; it
then returns a value of -1 with errno set to ECHILD (see
wait(2), waitid(2)).
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
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/