Thanks Alan. To follow-up, 2.1.5 was tested using my parameters, and the
condition did not reappear.
Cheers,
-- Stephen
Alan DeKok wrote:
Stephen Fulton wrote:
I forgot to ask, is the fix part of stable or development?
Both. The next release will be off of the "stable" tree.
Alan De
Stephen Fulton wrote:
> I forgot to ask, is the fix part of stable or development?
Both. The next release will be off of the "stable" tree.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan,
I forgot to ask, is the fix part of stable or development?
Thanks,
-- Stephen
Stephen Fulton wrote:
Thanks Alan, I'll do that.
-- Stephen
Alan DeKok wrote:
Stephen Fulton wrote:
Is there any way to mitigate these CPU issues in version 2.1.4?
No.
You will need to either upgrad
Thanks Alan, I'll do that.
-- Stephen
Alan DeKok wrote:
Stephen Fulton wrote:
Is there any way to mitigate these CPU issues in version 2.1.4?
No.
You will need to either upgrade, or *manually* pull the patches from
git into a local copy of 2.1.4.
Alan DeKok.
-
List info/subscribe/uns
Stephen Fulton wrote:
> Is there any way to mitigate these CPU issues in version 2.1.4?
No.
You will need to either upgrade, or *manually* pull the patches from
git into a local copy of 2.1.4.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi all,
First, I've used FreeRADIUS for a number of years in a number of installations,
and I'm fairly comfortable with it. I have looked through the archives, as well
as read the documentation, FAQ, wiki and the notes within each of the
configuration files that make up FR, such as the virtua
On Tue, 2005-02-08 at 00:08 +1100, Michael Mitchell wrote:
> Won't help much, but today I had an issue with a seg fault. Commented
> out a bit of code where the error was supposedly happening, seg fault
> went away... put the code back in...seg fault didn't return???
>
> Did a make clean; make a
Won't help much, but today I had an issue with a seg fault. Commented
out a bit of code where the error was supposedly happening, seg fault
went away... put the code back in...seg fault didn't return???
Did a make clean; make and everything seemed to be fine again. I guess
in the end I just had
On Fri, 2005-02-04 at 20:44 -0600, Michael Griego wrote:
> Try running with LD_ASSUME_KERNEL=2.4.19. This will force runtime
> linking against the standard libc libs instead of the thread-local
> storage (tls) libs. So, on the command line, run
> "LD_ASSUME_KERNEL=2.4.19 radiusd -X" and see if
Try running with LD_ASSUME_KERNEL=2.4.19. This will force runtime
linking against the standard libc libs instead of the thread-local
storage (tls) libs. So, on the command line, run
"LD_ASSUME_KERNEL=2.4.19 radiusd -X" and see if that segfaults.
--Mike
Alan DeKok wrote:
Daniel J McDonald <[EM
Daniel J McDonald <[EMAIL PROTECTED]> wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1076829024 (LWP 17140)]
> 0x40079e54 in pthread_mutex_lock () from /lib/tls/libpthread.so.0
> (gdb) bt
> #0 0x40079e54 in pthread_mutex_lock () from /lib/tls/libpthread.so.0
>
On Fri, 2005-02-04 at 18:15 -0500, Alan DeKok wrote:
> Daniel J McDonald <[EMAIL PROTECTED]> wrote:
> > Following up to myself, I just compiled 1.0.1 and had the same issues -
> > 97% cpu and does not send the authentication response, radiusd -X
> > generates a segmentation fault.
>
> That's ver
Daniel J McDonald <[EMAIL PROTECTED]> wrote:
> Following up to myself, I just compiled 1.0.1 and had the same issues -
> 97% cpu and does not send the authentication response, radiusd -X
> generates a segmentation fault.
That's very weird. I've never seen that myself...
> I changed radiusd.con
On Fri, 2005-02-04 at 14:42 -0600, Daniel J McDonald wrote:
> I have an instance of freeradius 1.0.0 that is consuming 60-100% of a
> cpu (I have a two-processor box, so I can watch it do this). I am using
> ldap for the backend database.
>
Following up to myself, I just compiled 1.0.1 and had t
I have an instance of freeradius 1.0.0 that is consuming 60-100% of a
cpu (I have a two-processor box, so I can watch it do this). I am using
ldap for the backend database.
clients.conf has about 160 devices in it, but this is the secondary box,
and there are only a few of us who use the radius s
t; Sent: Friday, January 28, 2005 8:04 PM
> To: freeradius-users@lists.freeradius.org
> Subject: Re: High CPU load, on accounting only server.
>
> On Fri, 28 Jan 2005 19:25:56 -0800, Justin LaVelle
> <[EMAIL PROTECTED]> wrote:
> >
> > High CPU load, on accounting o
PM
To: freeradius-users@lists.freeradius.org
Subject: Re: High CPU load, on accounting only server.
On Fri, 28 Jan 2005 19:25:56 -0800, Justin LaVelle
<[EMAIL PROTECTED]> wrote:
>
> High CPU load, on accounting only server.
> It using all available CPU, and not keeping up with what's b
On Fri, 28 Jan 2005 19:25:56 -0800, Justin LaVelle
<[EMAIL PROTECTED]> wrote:
>
> High CPU load, on accounting only server.
> It using all available CPU, and not keeping up with what's being sent to
> it.
> It's a P3 900Mhz. Fedora Core 3, freeradius 1.0.1 instal
High CPU load, on accounting only server.
It using all available CPU, and not keeping up with what's being sent to
it.
It's a P3 900Mhz. Fedora Core 3, freeradius 1.0.1 installed from "yum
install".
I'm accepting radius accounting data from several Redback SMS1800s (7 i
>
> Tuc <[EMAIL PROTECTED]> wrote:
> > Still, is there something if I do run the debug mode again that
> > we need to look for about these threads that seem to get used up, or
> > unresponsive children?
>
> Look for pauses. If a thread is dead, that means it's blocking for
> more than 5 se
Tuc <[EMAIL PROTECTED]> wrote:
> Still, is there something if I do run the debug mode again that
> we need to look for about these threads that seem to get used up, or
> unresponsive children?
Look for pauses. If a thread is dead, that means it's blocking for
more than 5 seconds. If you
>
> Tuc <[EMAIL PROTECTED]> wrote:
> > BEGIN failed--compilation aborted at /usr/local/radius/etc/raddb/scripts/login.p
> > l line 15.
> >
> > Could this be related to the Perl issue your seeing in GNA?
>
> I'm not sure what you mean by that.
>
Sorry, faded out there for a second.
I believe that 4.9 installs perl 5.6 as the default and it appears to be
looking for 5.005. Perhaps you need to reinstall the perl DBI or run a
portupgrade on it. Or change the path to perl in your script?
/usr/ports/databases/p5-DBI
Just a shot in the dark, hope that is helpful.
On Thu, 10
Tuc <[EMAIL PROTECTED]> wrote:
> BEGIN failed--compilation aborted at /usr/local/radius/etc/raddb/scripts/login.p
> l line 15.
>
> Could this be related to the Perl issue your seeing in GNA?
I'm not sure what you mean by that.
I wouldn't be surprised if that problem was the root cause
Hi,
I just ran it in debug as per the FAQ, and in the first few seconds
I noticed:
Can't locate DBI.pm in @INC (@INC contains: /usr/local/radius/etc/raddb/scripts
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd /usr/local/lib/perl5/site_perl
/5.005 . /usr/libdata/perl/5.00503/mach /usr
Tuc <[EMAIL PROTECTED]> wrote:
> When it starts to chew CPU, I see alot of :
>
> poll(0x81c7c00,0x3,0x0) = 0 (0x0)
> gettimeofday(0xbfbfeabc,0x0) = 0 (0x0)
...
> Does this seem odd?
Yes. It looks like the main loop which reads requests i
Hi,
When it starts to chew CPU, I see alot of :
poll(0x81c7c00,0x3,0x0) = 0 (0x0)
gettimeofday(0xbfbfeabc,0x0) = 0 (0x0)
poll(0x81c7c00,0x3,0x0) = 0 (0x0)
gettimeofday(0xbfbfeabc,0x0) = 0 (0x0)
poll(
>
> Tuc <[EMAIL PROTECTED]> wrote:
> > We've started to see things like :
> >
> > Mon Jun 7 11:00:13 2004 : Info: The maximum number of threads (32) are active,
> > cannot spawn new thread to handle request
> > Mon Jun 7 11:00:14 2004 : Error: Dropping packet from client L3-LasVegas:58096 -
>
Tuc <[EMAIL PROTECTED]> wrote:
> We've started to see things like :
>
> Mon Jun 7 11:00:13 2004 : Info: The maximum number of threads (32) are active,
> cannot spawn new thread to handle request
> Mon Jun 7 11:00:14 2004 : Error: Dropping packet from client L3-LasVegas:58096 - ID:
> 220 due to d
Hi,
We recently upgraded a machine from FreeBSD 4.7-STABLE to
4.9-RELEASE-p10, that was running FreeRadius 0.9.3 with the :
./configure --prefix=/usr/local/radius \
--with-thread-pool \
--enable-ltdl-install
and a MySQL back end.
We decided maybe there
30 matches
Mail list logo
