Re: SIGHUP signal to RADIUS processes
Brian Moore (bem@cmc.net)
Thu, 27 Mar 1997 11:11:13 -0800 (PST)
> > Keith K Chau <keithc@unitech.com.hk> wrote:
> >
> > > We have a customer who runs a PM-25 and RADIUS 2.0 (on Solaris).
> > > Recently, he gets many repeating error messages all over his console
> > > screen, which resembles the following:
> > >
> > > "Mar 20 11:15:39 hn radius [22313]:Sending SIGHUP signal to
> > > unresponsive child process 22328."
> > >
> > > Anyone knows what the possible cause is?
> >
> > In my opinion this problem is caused by a bug in Radius 2.0
>
> These messages happen when a radiusd child process, spawned off to
> handle a service request, doesn't die of its own accord (as it should)
> after completing its mission. The parent process goes round every now
> and then and reaps any child processes that don't do this. The
> messages are most commonly seen on RADIUS servers which are busy
> computers - the child processes don't get enough CPU time to die on
> their own before the parent gets around to reaping them.
Well, not in our case. RADIUS is running on an SS20 that is 92% idle. It's
not really a bug in radiusd, it is, I believe, a Solaris oddity in how it deals
with signals, specifically SIGCLD versus SIGCHLD.
(Note that on Slugaris 2.5, the signal(3C) man page talks about SIGCHLD whilst
/bin/kill -l lists CLD as the proper one. Why do I think not even Sun knows
whether it's SysVish BSD or BSDish SysV anymore? They claim CLD is there for
'compatibility' reasons, ignoring some semantical differences between the two
and then leaving CLD as the preferred one in /bin/kill.)
Anyway, the fix to kill the log spam is to use the -s flag on radiusd.
Some day when I'm REALLY bored I'll dig up my Stevens and figure out what the
problem is.
Repeat 1000 times: System V Signals Suck.