Unexpected "Exiting normally" 2.1.8?
aland at deployingradius.com
Thu Nov 26 07:45:59 CET 2009
Bjørn Mork wrote:
> I am now seeing this very same problem, and strongly suspect it to be
> related to dead proxy home servers. I was able to provoke the "Exiting
> normally" on a server with *no* traffic at all, by doing a couple of
> requests for a realm with dead home servers and then waiting:
> Wed Nov 25 18:03:56 2009 : Error: PROXY: Marking home server 88.a.b.158 port 1812 as zombie (it looks like it is dead).
> Wed Nov 25 18:04:35 2009 : Error: PROXY: Marking home server 84.c.d.222 port 1812 as zombie (it looks like it is dead).
> Wed Nov 25 19:38:13 2009 : Info: Exiting normally.
> No requests at all were sent to this server between the two last log
Hmm... the "exiting normally" means that it received a signal to exit
(internal or external). Otherwise, it just keeps running.
Try using gdb, and:
(gdb) break event_loop_exit
(gdb) break radius_signal_self
(gdb) cond 1 (flag == 2)
And then when it stops:
(gdb) thread apply all bt full
That *should* catch the stack trace where it exits.
> I was planning to use the 2.1.7 release, but hit the recursive mutex
Ugh. Some systems don't support recursive mutexes, and even better,
don't complain when you try to use them!
> Now, adding the two facts, I'm starting to wonder whether the
> "Exiting normally" bug might be related to the fix for the recursive
> mutexes? They are both related to dead home servers. Makes me
Quite possibly, yes. But the fact that it exits a minute and a half
after the last packet is odd.
> And I'm wondering what my other options are wrt the mutex problem. I am
> pretty much stuch with RHEL on these servers (not my choice). Is this a
> glibc 2.5 problem? Should I demand an upgrade to a more modern OS?
Let's wait for the back trace.
More information about the Freeradius-Users