Re: Possible task exit bug?

David Wragg (dpw@doc.ic.ac.uk)
24 May 1999 23:29:00 +0000


Jonathan Larmour <jlarmour@cygnus.co.uk> writes:
> [snip code]
>
> If I run this directly from the shell, its fine - there's no output. If I
> run it from a cron or "at" job on Linux I get "error: No child processes"
> i.e. ECHILD. This works on Solaris but fails on both linux 2.0.36/glibc2.0
> and linux 2.2.2/glibc2.1. But its not clear to me why it succeeds on a tty,
> but not from cron. I get the same effect on a tty if I put an explicit
> "signal(SIGCHLD, SIG_IGN);" near the top.

POSIX says that if SIGCHLD is set to SIG_IGN then child zombies get
automatically reaped. So what is happening within the program is
basically what should happen. The solution is do an explicit
"signal(SIGCHLD, SIG_DFL)" in your program.

The cron behaviour seems unhelpful though. But it's worth noting that
the Unix way has always been that the signal settings (both the
handler setting and signal mask) when a program starts cannot be
relied upon. Lots of programs explicitly see to this when they start
up to avoid problems.

> An strace shows that the SIGCHLD is getting sent, but analysis with ps shows
> that in the case where it is run from a tty, the zombie stays around; but
> when run from cron, the child just disappears immediately.

Yes, the SIGCHLD does actually get sent (unlike most other signals set
to SIG_IGN, which disappear early on and so are never pending). But
the kernel does a wait internally (it happens in do_signal() in
arch/i386/kernel/signal.c) and consumes the signal. So it your
program, the sleep gets interrupted and when your wait is reached
there is nothing left to wait on.

However, I'm not sure if SIGCHLD when set to SIG_IGN should interrupt
system calls according to POSIX.

David Wragg

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