Unexpected "Exiting normally" 2.1.8?

[Craig Campbell]

Here are the results from the latest gdb,

[[root at 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" <aland at deployingradius.com>
To: "FreeRadius users mailing list" <freeradius-users at 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