reinstalling SIGCHLD handler before wait()

Markus Friedl markus.friedl at informatik.uni-erlangen.de
Wed Dec 13 10:57:28 EST 2000


i wrote this code and i'd prefer signal handlers that
only set flags and do _not_ call waitpid etc. moreover, i
don't want to have to re-install the signal handler.
i'll read my stevens again.

On Wed, Dec 13, 2000 at 12:47:08AM +0100, Kevin Steves wrote:
> HP-UX 11 is looping on SIGCHLD/sigchld_handler2() when exiting a
> protocol 2 session apparently because we don't call wait before
> reinstalling the handler.  Any thoughts on this issue or how to address
> it?
> 
> serverloop.c from latest snapshots:
> 
> void
> sigchld_handler2(int sig)
> {
> 	int save_errno = errno;
> 	debug("Received SIGCHLD.");
> 	child_terminated = 1;
> 	signal(SIGCHLD, sigchld_handler2);
> 	errno = save_errno;
> }
> 
> from signal(5) on HP-UX 11 (SIGCLD is the same as SIGCHLD):
> 
>                 If one of the signal interface routines is used to
>                           set the action for SIGCLD to be caught (that is, a
>                           function address is supplied) in a process that
>                           currently has terminated (zombie) children, a
>                           SIGCLD signal is delivered to the parent process
>                           immediately.  Thus, if the signal-catching
>                           function reinstalls itself, the apparent effect is
>                           that any SIGCLD signals received due to the death
>                           of children while the function is executing are
>                           queued and the signal-catching function is
>                           continually reentered until the queue is empty.
>                           Note that the function must reinstall itself after
>                           it calls wait(), wait3(), or waitpid().  Otherwise
>                           the presence of the child that caused the original
>                           signal causes another signal immediately,
>                           resulting in infinite recursion.     
> 
> 





More information about the openssh-unix-dev mailing list