Hi,
I have 2 servers with identical hardware/software configs.
Both servers hang at the same time.
stopping/starting the daemon doesn't resolve the issue, rebooting the box
does.
Well, in my case the server doesn't respond to a normal kill, so the
start/stop scripts indeed wouldn't do the
.
- Original Message -
From: Stefan Winter [EMAIL PROTECTED]
To: FreeRadius users mailing list freeradius-users@lists.freeradius.org
Sent: Monday, April 10, 2006 1:13 AM
Subject: Re: Version 1.1.1 stops responding
Hi,
I have 2 servers with identical hardware/software configs.
Both
Duane Cox [EMAIL PROTECTED] wrote:
I have 2 servers with identical hardware/software configs.
Both servers hang at the same time.
stopping/starting the daemon doesn't resolve the issue, rebooting the box
does.
That's fairly bad. I'm not sure how something in the application
layer could
On Apr 9, 2006, at 17:46, Alan DeKok wrote:
Duane Cox [EMAIL PROTECTED] wrote:
I have 2 servers with identical hardware/software configs.
Both servers hang at the same time.
stopping/starting the daemon doesn't resolve the issue, rebooting
the box
does.
That's fairly bad. I'm not
that is
where it paused (see: sql hangs, was (conflicts/duplicates need))
- Original Message -
From: King, Michael [EMAIL PROTECTED]
To: FreeRadius users mailing list freeradius-users@lists.freeradius.org
Sent: Thursday, March 23, 2006 9:24 AM
Subject: Version 1.1.1 stops responding
So I
Stefan Winter [EMAIL PROTECTED] wrote:
When I did it in -X mode, it segfaulted. The end of the -X output is:
...
Could you do the same, but with core dumps enabled (ulimit -c
unlimited) and symbols?
That would help a lot in tracking down the problem.
Also, what OS you're running on, etc.
On Mon, 2006-03-27 at 17:37 -0500, Alan DeKok wrote:
(gdb) info threads
That *may* be enough. What will also help (if you have symbols) is:
(gdb) thread 1
(gdb) bt
(gdb) thread 2
(gdb) bt
(gdb) thread 3
(gdb) bt
...
The easiest way of doing this is
(gdb) thread apply all bt
on
Stuart Auchterlonie [EMAIL PROTECTED] wrote:
The easiest way of doing this is
(gdb) thread apply all bt
...
Thanks. I've updated doc/bugs with that information.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Winter
Sent: Monday, March 27, 2006 1:49 AM
To: FreeRadius users mailing list
Subject: Re: Version 1.1.1 stops responding
Mine seg faulted as well..
Here's the last few lines of the freeradius -X -A
modcall: entering group authenticate for request 1002
rlm_eap: Request found
Stefan Winter [EMAIL PROTECTED] wrote:
Interesting. This morning I encountered again that radiusd was claiming to be
still listening on its ports, but didn't process anything any more. As other
logs showed, someone logged into an Access Point via TTLS at 8:22 and at 8:25
the Nagios
-Original Message-
From:
adius.org] On Behalf Of Alan DeKok
Until we can get more information about what's happening
(strace/ktrace, or gdb backtrace), there isn't much anyone
can do to fix it.
How would I create those traces? (I'm looking for a suggested command
line, since
King, Michael [EMAIL PROTECTED] wrote:
How would I create those traces? (I'm looking for a suggested command
line, since I don't normally use those programs)
I'd suggest gdb, and do it in a testing environment if at all
possible, to avoid hitting your main server. Also, you *must* have
King, Michael [EMAIL PROTECTED] wrote:
I wonder if this has something to do with this bug that got squashed
2006.03.20 v1.0.5, and v1.1.0 - A validation issue exists with the
EAP-MSCHAPv2 module
No. EAP-MSCHAP doesn't do TLS, and that code change cannot affect
anything but people
Mine seg faulted as well..
Here's the last few lines of the freeradius -X -A
modcall: entering group authenticate for request 1002
rlm_eap: Request found, released from the list
rlm_eap: EAP/peap
rlm_eap: processing type peap
rlm_eap_peap: Authenticate
rlm_eap_tls: processing
I'm running it in debug mode (and piping it to a file)
Freeradius -X -A crash.log
After a few hours this is what I got.
On the command line.
rad2:/home/mking# /usr/sbin/freeradius -X -A crash.log
Killed
rad2:/home/mking#
The last few lines from the log file are
rlm_eap: Request found,
Hi,
I have a follow-up as well. After configuring everything for doing SIGHUPs it
turned out that after a SIGHUP, the process sits there and does nothing any
more.
When I did killall -HUP radiusd in non-debug mode, the process kept running,
but didn't process anything any more.
When I did it
Mine seg faulted as well..
(This time I didn't overwrite the log)
rad2:/home/mking# /usr/sbin/freeradius -X -A crash.log
Segmentation fault
rad2:/home/mking#
I don't believe running /usr/sbin/freeradius -X -A is capturing anything
useful. Is there something else I can do?
Here's the last
So I built 1.1.1 on Debian.
After a period of so many hours (variable) it stops responding.
(Sometimes 2hours, sometimes 16hours)
Now here's where it get's weird, (and makes me suspect it might not be
freeRADIUS at the root cause)
If I stop and restart the freeRADIUS service, it continues to
On Thu, 2006-03-23 at 09:24 -0500, King, Michael wrote:
So I built 1.1.1 on Debian.
After a period of so many hours (variable) it stops responding.
(Sometimes 2hours, sometimes 16hours)
Now here's where it get's weird, (and makes me suspect it might not be
freeRADIUS at the root cause)
Hi,
I am seeing a similar problem on RedHat. I originally thought it was
only happening when I sent a HUP signal, but it turns out this is not
the case.
However in my case all I have to do to fix it is restart the service (I
do not need to reboot the entire operating system).
for the
20 matches
Mail list logo