From: Scott Merrilees <Sm@cerberus.bhpese.oz.au>
When doing a rsh command to a solaris 2.2 box, I find that the rc
started by rshd hangs in a cpu loop after the command has terminated.
Interestingly, SIGCLD is ingored in both rshd & rc. Has anyone else
fixed this problem ?
>From: noel@es.su.oz.au
>it's not that rc _ignores_ SIGCLD, it just doesn't touch it. when rc
>is started by login and forks a program, you will notice that SIGCLD
>is SIG_DFL. but when rc is started by rshd, it must be set to SIG_IGN.
>bad shit happens in sysvr4 when this is done, namely, a parent is not
>notified of the death of a child, so rc just sits in that wait loop
>waiting to pick up the status of the child it just forked, a status
>it will never get. i noticed the cpu in a tight loop when this happened.
>
>anyway, i just hacked the code to make sure SIGCLD is _always_ SIG_DFL.
>this seems to fix the problem.
That was my guess, I figure that rshd must be doing a process id
specific wait, such as waitpid(), and doesn't want to get hit with
SIGCLD signals.
After looking in fn.c:setsigdefaults(), I came up with the following
patch to fn.c:inithandlers(). This seems to work. The patch is
relative to rc-1.4.
Sm
--
*** fn.c.orig Tue Mar 29 12:37:04 1994
--- fn.c Tue Mar 29 12:39:16 1994
***************
*** 45,50 ****
--- 45,54 ----
fnrm("sigterm"); /* ditto for SIGTERM */
}
}
+ #ifdef NOSIGCLD
+ rc_signal(SIGCLD, SIG_DFL);
+ delete_fn(signals[SIGCLD].name);
+ #endif
}
/* only run this in a child process! resets signals to their default values */