I found Chris Parker's email suggesting to use `gdb radiusd` `set args
-X` do stuff until it crashes, then run `bt` at the gdb prompt. First
of all, running the server -X works, so set args -X would not reproduce
the problem so I ran set args -f instead to keep it in the forground. I
ran the first auth and it worked, but the server didn't die so I
SIGINT'd it inside gdb with CTRL-C, then ran bt. Here's what I got.
For some reason I don't think this is going to be very helpful :(
[root@industry jlixfeld]# gdb /services/radius/freeradius/sbin/radiusd
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) set args -f
(gdb) run
Starting program: /services/radius/freeradius/sbin/radiusd -f
[New Thread 1024 (LWP 1347)]
radiusd: Starting - reading configuration files ...
radiusd: Core dumps are enabled.
[New Thread 2049 (LWP 1353)]
Delayed SIGSTOP caught for LWP 1353.
[New Thread 1026 (LWP 1354)]
Delayed SIGSTOP caught for LWP 1354.
Password = "letmein"
Framed-IP-Address = 10.10.10.255
Framed-IP-Address = 10.10.10.255
Service-Type = Framed-User
Framed-IP-Address = 10.10.10.255
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Address = 10.10.10.255
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Netmask = 255.255.255.255
Program received signal SIGINT, Interrupt.
[Switching to Thread 1024 (LWP 1347)]
0x080569b1 in thread_pool_clean (now=1004725074) at threads.c:537
537 for (handle = thread_pool.head; handle; handle =
handle->next) {
(gdb) bt
#0 0x080569b1 in thread_pool_clean (now=1004725074) at threads.c:537
#1 0x0804da24 in rad_clean_list (now=1004725074) at radiusd.c:1756
#2 0x0804d001 in main (argc=2, argv=0xbffff934) at radiusd.c:1085
#3 0x400aa177 in __libc_start_main (main=0x804c3cc <main>, argc=2,
ubp_av=0xbffff934, init=0x804b464 <_init>,
fini=0x805cc00 <_fini>, rtld_fini=0x4000e184 <_dl_fini>,
stack_end=0xbffff92c) at ../sysdeps/generic/libc-start.c:129
(gdb)
Is it helpful?
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of
> Jason Lixfeld
> Sent: November 2, 2001 12:54 PM
> To: [EMAIL PROTECTED]
> Subject: Problems starting radiusd - Again :(
>
>
> Alan, remembber this glitch from a couple weeks ago? It's back!
>
> For the last week, I've been running the server -X to debug
> this latest auth problem that Mitry's patch fixed. Now,
> getting ready to drop this into production, I ran the server
> with no flags and again it authenticated the first user, then
> the CPU shot up to 99%. Running the server with -s (or -X
> which is also single threaded mode, I assume) works fine;
> that is I can authenticate users until the cows come home
> with no problems.
>
> I'm going to dig around in my notes and see if I can find the
> gdb syntax I was given those two weeks ago. I'll run it
> again and post the output, I'm just letting you know that
> this is happening again.
>
> FYI: Kernel 2.4.9 SMP.
> HW: Dell PowerEdge 2450, Dual PIII-800, 768MB RAM, 5x32GB SCSI in
> RAID5, Dell Raid Controller 3/Si (rev2), EXT3 FS.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: October 24, 2001 3:18 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Problems starting radiusd
> >
> >
> > "Jason Lixfeld" <[EMAIL PROTECTED]> wrote:
> > > I've done a little digging but I can't find the answer. Radiusd
> > > starts fine in all circumstances. It will authenticate only one
> > > session, and then the CPU will spike to 100% and radtest
> > will just run
> > > through it's 10 cycles and timeout.
> >
> > Which version of the server are you running? The CVS
> > snapshot has a lot of bugs fixed over older versions.
> >
> > If you see a bug in an older version, you should upgrade to
> > the latest CVS snapshot, and see if the bug is there, too.
> >
> > > This happens when I run radiusd in any of the following ways:
> > >
> > > Radiusd
> > > Radiusd -f
> >
> > Uh, no. I like to be *exact* about what's going on. The
> > server does NOT use a capital 'R' for it's name. It's name
> > is "radiusd".
> >
> > It's a small point, but being exact helps.
> >
> > > It runs just fine when I run radiusd with the -s flag in
> any of the
> > > top examples. Any one know why this might be happening?
> >
> > With -s, it's running in single user mode. Without it,
> > it's using multiple threads or processes.
> >
> > I would STRONGLY recommend using threads. If you turn
> > those off, then there's no telling what the server will do.
> >
> > > FYI: If I run -fxx, I get no debugging information from
> > the server at
> > > all, so unfortunately it's not going to be any help :(
> >
> > Then something else strange is going on. When run via
> > 'radiusd -X', (or -xx', the server produces debugging information.
> >
> > Are you sure that the server binary is FreeRADIUS?
> >
> > Alan DeKok.
> >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
> >
>
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
