Here are the results from the latest gdb,
[[r...@radius-a ~]# gdb radiusd
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) break event_loop_exit
Function "event_loop_exit" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (event_loop_exit) pending.
(gdb) break radius_signal_self
Breakpoint 2 at 0x434d9f: file event.c, line 3733.
(gdb) cond 1 (flag == 2)
(gdb) run -f
Starting program: /usr/local/sbin/radiusd -f
Error in re-setting breakpoint 1: Function "event_loop_exit" not defined.
[Thread debugging using libthread_db enabled]
[New Thread 0x2b8a5990de10 (LWP 543)]
[New Thread 0x41850940 (LWP 551)]
[New Thread 0x42400940 (LWP 552)]
[New Thread 0x42e01940 (LWP 553)]
[New Thread 0x43802940 (LWP 554)]
[New Thread 0x44203940 (LWP 555)]
Detaching after fork from child process 556.
Detaching after fork from child process 557.
Detaching after fork from child process 616.
<snip>
Detaching after fork from child process 5364.
Detaching after fork from child process 5394.
[Switching to Thread 0x45605940 (LWP 4185)]
Breakpoint 2, radius_signal_self (flag=8) at event.c:3733
3733 rcode = read(self_pipe[0], buffer, sizeof(buffer));
(gdb)
Thanks,
-craig
----- Original Message -----
From: "Alan DeKok" <al...@deployingradius.com>
To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org>
Sent: Thursday, November 26, 2009 1:45 AM
Subject: Re: Unexpected "Exiting normally" 2.1.8?
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
lines.
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)
(gdb) run
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
problem.
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
suspicious...
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.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
__________ Information from ESET Smart Security, version of virus signature
database 4636 (20091125) __________
The message was checked by ESET Smart Security.
http://www.eset.com
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
