Unexpected "Exiting normally" 2.1.8?

Fri Nov 6 13:04:17 CET 2009

Ok,
 I performed the following on two servers that relay receive accounting 
packets only and relay these to each other (if it matters).

This is the same test code the Alan had me build, with his custom event.c. 
(I really do not know how to use git)
I deleted the existing installation, and then performed the following steps.

    CFLAGS='-O0 -g' ./configure
    make clean
    make
    sudo make install

I then ran the code from within gdb as Alexander described (within screen - 
thanks!)

    gdb radiusd
    (gdb) run -f
    <messages program runs until...>
    Detaching after fork from child process 14277.
    Detaching after fork from child process 14334.
    Detaching after fork from child process 14364.
    Detaching after fork from child process 14394.
    Detaching after fork from child process 14424.

    Program received signal SIGTERM, Terminated.
    0x0000003acf4306a7 in kill () from /lib64/libc.so.6
    (gdb) where
    #0  0x0000003acf4306a7 in kill () from /lib64/libc.so.6
    #1  0x0000000000424186 in main (argc=2, argv=0x7fff67ce72d8) at 
radiusd.c:419
    (gdb)

The gdb output is identical for the other radius server.

I'm afraid  I haven't helped much.  The source I have was acquired Oct 20 
15:05 (EST) if that helps in any way.  Perhaps I have fewer of the suspected 
patches in my build than you have in yours?  Is there a way we could 
compare?

Is there any way I can get more information out of these test runs?

Thanks,
-craig

----- Original Message ----- 
From: "Alexander Clouter" <alex at digriz.org.uk>
To: <freeradius-users at lists.freeradius.org>
Sent: Wednesday, November 04, 2009 3:47 PM
Subject: Re: Unexpected "Exiting normally" 2.1.8?

> Craig Campbell <craig at ccraft.ca> wrote:
>>
>>  Thanks for the update - I was concluding I'd have to wait for the 
>> release
>> of 2.1.8 to pursue this.  I am currently in a situation where I can help
>> debug 2.1.8, since the 'new' systems aren't yet in production.
>>
> Well I can see no reason to run FreeRADIUS no in a debugger all the
> time, even when in production.  However my nickname is "Rambo Clouter"
> so maybe you do not want to follow my advice. :)
>
> When you compile FreeRADIUS you simply make sure you leave
> debugging symbols in and turn off compiler optimisations (so your CFLAGS
> should be '-O0 -g'.  You probably can do this by running configure as
> follows:
> ----
> CFLAGS='-O0 -g' ./configure --all-your-usual-options-that-you-want
> ----
>
>> Looking at your debug output (and I am in no way an expert at that) it 
>> seems
>> as though the process received a signal?
>>
> Well FreeRADIUS is sending it to herself according to gdb:
> ---- src/main/radiusd.c line 419 ----
>        /*
>         *      Send a TERM signal to all
>         *      associated processes
>         *      (including us, which gets
>         *      ignored.)
>         */
> #ifndef __MINGW32__
>        if (spawn_flag) kill(-radius_pid, SIGTERM);
> #endif
> ----
>
> For whatever reason, it is not getting ignored.  At first I thought it
> was because I run my FreeRADIUS (even in production) in gdb, but as you
> do not I am wondering what is actually going on.
>
> To run it in the debugger just run 'gdb freeradius' and you will get the
> gdb prompt.  There you want to type 'run -f' and wait for it to puke.
> When it does you could type 'where' for it to tell you what happened,
> but we know what is happening, we want to find which patch is doing it
> :)  Oh familise yourself with screen[2] if you do not know it already,
> you should run the debugger in a screen'd session so you can return to
> it later without having to remain logged in.
>
>> I am running a 'custom' module (event.c as I recall) from Alan that 
>> resolves
>> an issue with hung children (very exciting!), and I followed Alan's
>> instructions to get to this point.  I would really like to try to 'give
>> back' if I can and assist in identifying the cause of the program exiting
>> (assuming it is a new and as of yet unidentified bug).
>>
>> Would copying the steps you have below on my two redhat systems be a good
>> way to proceed?
>>
> Pretty much follow:
>
> http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/
>
> I had been running with the cherry-pick'ed patches for weeks and had no
> problems up to 9261f3e0026323b2c397af13d02fbc5780908143, so I am certain
> that the issue is the result of the patches between
> 12ead56dffca9b3ecddc8a7860a1ef5b5361b374 and
> 9dbc8974fdd2300a70293eda9c62bce20a3c9165.  The problem is you *have* to
> apply my listed cherry-picks, as if you add *any* of the TCP related
> code Alan has been working on, it all stops compiling[1]
>
> Cheers
>
> [1] I am pretty sure Alan has stashed a number of patches that he has
> not put into the publically available GIT trees as things like
> the jumbo socket clean up patch
> (e04b62f1bd257489bd92ccc584b0886c7e2011e8) refer to
> my_ipaddr/my_port which is not in any header files I have or
> found in 'master'
> [2] http://blogamundo.net/code/screen/
> -- 
> Alexander Clouter
> .sigmonster says: Simplicity does not precede complexity, but follows it.
>
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html
>
> __________ Information from ESET Smart Security, version of virus 
> signature database 4574 (20091104) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
> 

__________ Information from ESET Smart Security, version of virus signature database 4578 (20091106) __________

The message was checked by ESET Smart Security.

http://www.eset.com