[4647] in Kerberos
Re: kadmin - Can't get it to work!
daemon@ATHENA.MIT.EDU (Axel-Stiphane C. Smxrgrav)
Mon Feb 20 09:00:01 1995
To: kerberos@MIT.EDU
Date: 20 Feb 1995 14:27:57 +0100
From: axelstep@ifi.uio.no (Axel-Stiphane C. Smxrgrav)
In article <3i5csh$oq1@necco.harvard.edu>, dm@das.harvard.edu (David Mazieres) writes:
> In article <3i3osf$2eu@news.doit.wisc.edu>,
> Bruce Orchard <orchard@eceserv0.ece.wisc.edu> wrote:
> >
> >I have kadmin working (but see below) on a Sun running Solaris 2.4.
> >...
> >
> >The problem is that when the client (kadmin) exits, the
> >server (kadmind) goes into a loop handling the SIGCHILD
> >signal. Thus if you start kadmind and run kadmin, kadmin
> >works once; then you have to kill kadmind and start over.
> >I think this just applies to SVR4/Solaris; it will probably
> >work OK on BSD/SunOS4.
>
> Yes, I had this problem under HP-UX, too. I fixed it by adding
> the following ifdef to function do_child in kadmin/server/adm_network.c:
> (first part is what was originally there)
>
> #ifndef __hpux
> signal(SIGCHLD, do_child);
> pid = wait(&status);
> #else /* __hpux */
> /*
> * HPUX will deliver an immediate signal if a child is pending,
> * resulting in infinite recursion!
> */
> pid = wait(&status);
> signal(SIGCHLD, do_child);
> #endif /* __hpux */
>
> I guess the problem affects more than just HP-UX, though.
No, that is right. This problem will probably affect all systemV-ish OS'es, and is
caused by differences in the semantics of SIGCHLD/SIGCLD.
Under SystemV, when a signal occurs, the signal handler is reset to SIG_DFL, and
hence the signal handler must be reinstalled. This is usually done in the signal
handler as shown in the above example (if-branch).
Normally a signal will occur only once for each event to be signalled. However,
SIGCHLD is different. When reinstalled, the system checks if there are any child
processes to be waited for, and if there are, the parent process receives a new
occurence of SIGCHLD. This results in the signal handler being called recursively
over and over again, until the process eventually trashes as the result of a stack
overflow.
-ascs
