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
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
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
20 matches
Mail list logo
