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
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
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
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
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
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
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 that
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
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 and
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
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 the
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.conf to
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 very weird.
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
#1
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
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 being sent
to
it.
It's a P3 900Mhz. Fedora Core 3
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 in
total)
I'm just logging
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 installed from yum
install.
I'm accepting
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
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
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 is
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. This was
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 run
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
24 matches
Mail list logo