%RADIUS-4-RADIUS_ALIVE | %RADIUS-4-RADIUS_DEAD help
I'm seeing the following weirdness from my freeradiusserver and when i see the radiusd process its stopped status. why this happens. any valid reasons for this? Apr 26 00:18:44.498: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive. Apr 26 00:18:50.777: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding. Apr 26 00:18:50.777: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive. Apr 26 00:18:59.133: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding. Apr 26 00:18:59.133: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive. Apr 26 00:19:04.765: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding. Thanks in advance. Regards, Rams.
Am 27.04.2009 um 09:08 schrieb ramesh p:
I'm seeing the following weirdness from my freeradiusserver and when i see the radiusd process its stopped status. why this happens. any valid reasons for this?
Apr 26 00:18:44.498: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:19:04.765: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding. Thanks in advance.
Have you checked the output of radiusd -X if there is a reason given or any other hint?
Regards, Rams. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html
Have a nice day! Nicolas Goutte extragroup GmbH - Karlsruhe Waldstr. 49 76133 Karlsruhe Germany Geschäftsführer: Stephan Mönninghoff, Hans Martin Kern, Tilman Haerdle Registergericht: Amtsgericht Münster / HRB: 5624 Steuer Nr.: 337/5903/0421 / UstID: DE 204607841
Hi there, I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages. On 27.04.2009, at 10:42, Nicolas Goutte wrote:
Am 27.04.2009 um 09:08 schrieb ramesh p:
I'm seeing the following weirdness from my freeradiusserver and when i see the radiusd process its stopped status. why this happens. any valid reasons for this?
Apr 26 00:18:44.498: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:19:04.765: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding. Thanks in advance.
Have you checked the output of radiusd -X if there is a reason given or any other hint?
Regards, Rams. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Have a nice day!
Nicolas Goutte
extragroup GmbH - Karlsruhe Waldstr. 49 76133 Karlsruhe Germany
Geschäftsführer: Stephan Mönninghoff, Hans Martin Kern, Tilman Haerdle Registergericht: Amtsgericht Münster / HRB: 5624 Steuer Nr.: 337/5903/0421 / UstID: DE 204607841
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks. How to configure it? On Mon, Apr 27, 2009 at 1:29 PM, Borislav Dimitrov <b.dimitrov@ngsystems.net
wrote:
Hi there, I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
On 27.04.2009, at 10:42, Nicolas Goutte wrote:
Am 27.04.2009 um 09:08 schrieb ramesh p:
I'm seeing the following weirdness from my freeradiusserver and when i see the radiusd process its stopped status. why this happens. any valid reasons for this?
Apr 26 00:18:44.498: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:19:04.765: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding. Thanks in advance.
Have you checked the output of radiusd -X if there is a reason given or any other hint?
Regards, Rams. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Have a nice day!
Nicolas Goutte
extragroup GmbH - Karlsruhe Waldstr. 49 76133 Karlsruhe Germany
Geschäftsführer: Stephan Mönninghoff, Hans Martin Kern, Tilman Haerdle Registergericht: Amtsgericht Münster / HRB: 5624 Steuer Nr.: 337/5903/0421 / UstID: DE 204607841
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
And why the process is stopped automaticaly? any reasons. On Mon, Apr 27, 2009 at 2:05 PM, ramesh p <rock786143@gmail.com> wrote:
Thanks. How to configure it?
On Mon, Apr 27, 2009 at 1:29 PM, Borislav Dimitrov < b.dimitrov@ngsystems.net> wrote:
Hi there, I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
On 27.04.2009, at 10:42, Nicolas Goutte wrote:
Am 27.04.2009 um 09:08 schrieb ramesh p:
I'm seeing the following weirdness from my freeradiusserver and when i see the radiusd process its stopped status. why this happens. any valid reasons for this?
Apr 26 00:18:44.498: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:19:04.765: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding. Thanks in advance.
Have you checked the output of radiusd -X if there is a reason given or any other hint?
Regards, Rams. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Have a nice day!
Nicolas Goutte
extragroup GmbH - Karlsruhe Waldstr. 49 76133 Karlsruhe Germany
Geschäftsführer: Stephan Mönninghoff, Hans Martin Kern, Tilman Haerdle Registergericht: Amtsgericht Münster / HRB: 5624 Steuer Nr.: 337/5903/0421 / UstID: DE 204607841
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Why do you think that the process is stopped? It's probably sleeping which is its normal state if you're looking at the `ps`s output. About the thread pool, check the documentation. Anyways, here's what it looks like: # THREAD POOL CONFIGURATION thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 } Configure there according to the expected load. rlm_perl (if you're using it at all) has options for configuring the number of Perl interpreters also but they are to be deprecated since 2.1.5 so don't use them: # MODULE CONFIGURATION modules { perl { module = /Users/everlast/development/blah.pl func_accounting = accounting max_clones = 1 start_clones = 1 min_spare_clones = 0 max_spare_clones = 1 cleanup_delay = 5 max_requests_per_clone = 0 } } As you can see, it's similar to Apache's thread pool settings. Put higher numbers in the thread pool section (check the defaults in the docs also) and start FreeRADIUS without -X (debug mode) but just like that: radiusd & If your setup requires loading a lot of setting (from a DB or something) on start-up setup things so that the started number of threads is static (like in the example) - so that it doesn't start/ stop threads depending on the load because this (loading a huge configuration/user data database on start up) can cripple things up. On 27.04.2009, at 11:36, ramesh p wrote:
And why the process is stopped automaticaly? any reasons.
On Mon, Apr 27, 2009 at 2:05 PM, ramesh p <rock786143@gmail.com> wrote: Thanks. How to configure it?
On Mon, Apr 27, 2009 at 1:29 PM, Borislav Dimitrov <b.dimitrov@ngsystems.net
wrote: Hi there,
I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
On 27.04.2009, at 10:42, Nicolas Goutte wrote:
Am 27.04.2009 um 09:08 schrieb ramesh p:
I'm seeing the following weirdness from my freeradiusserver and when i see the radiusd process its stopped status. why this happens. any valid reasons for this?
Apr 26 00:18:44.498: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:50.777: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding.
Apr 26 00:18:59.133: %RADIUS-4-RADIUS_ALIVE: RADIUS server X.X.X.X:0,1813 is being marked alive.
Apr 26 00:19:04.765: %RADIUS-4-RADIUS_DEAD: RADIUS server X.X.X.X:0,1813 is not responding. Thanks in advance.
Have you checked the output of radiusd -X if there is a reason given or any other hint?
Regards, Rams. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Have a nice day!
Nicolas Goutte
extragroup GmbH - Karlsruhe Waldstr. 49 76133 Karlsruhe Germany
Geschäftsführer: Stephan Mönninghoff, Hans Martin Kern, Tilman Haerdle Registergericht: Amtsgericht Münster / HRB: 5624 Steuer Nr.: 337/5903/0421 / UstID: DE 204607841
- 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
Well, has it? Servers don't just go dead and back alive just like that. It's much more likely that server was never dead at all. Stop looking at NAS messages and examine why radius server didn't respond: - did it get the request at all? Maybe your network is loosing packets. - did something else fail (sql, ldap) and radius is blocked waiting for it? - did it respond but took too long to process the request? - or was it really dead? Find out first what's wrong. Then work on fixing it. Trying random solutions is not a very good way forward. Ivan Kalik Kalik Informatika ISP
Thanks alot for providing very good suggestions. On Mon, Apr 27, 2009 at 4:12 PM, Ivan Kalik <tnt@kalik.net> wrote:
Well, has it? Servers don't just go dead and back alive just like that. It's much more likely that server was never dead at all. Stop looking at NAS messages and examine why radius server didn't respond:
- did it get the request at all? Maybe your network is loosing packets.
- did something else fail (sql, ldap) and radius is blocked waiting for it?
- did it respond but took too long to process the request?
- or was it really dead?
Find out first what's wrong. Then work on fixing it. Trying random solutions is not a very good way forward.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, are you sure that the accounting server was ever alive and handling accounting packets? Those logs look exactly like they would if , for example, you were sending auth+acct to an IAS RADIUS server not configured for accounting. the RADIUS server attempts to send an accounting packet to it...doesnt get an accounting response. marks it as dead...has a timer, knows no better than presume it alive and then back to step one. rinse and repeat alan
Accounting server was alive and receving packets till yesterday. And suddenly got receiving dead alive messages. So restarted radiusd process then it got resolved. However it repeating frequently once a week.... Unable to findout the exact reason for this. On Mon, Apr 27, 2009 at 4:38 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
are you sure that the accounting server was ever alive and handling accounting packets? Those logs look exactly like they would if , for example, you were sending auth+acct to an IAS RADIUS server not configured for accounting.
the RADIUS server attempts to send an accounting packet to it...doesnt get an accounting response. marks it as dead...has a timer, knows no better than presume it alive and then back to step one. rinse and repeat
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Accounting server was alive and receving packets till yesterday. And suddenly got receiving dead alive messages. So restarted radiusd process then it got resolved.
are we talking about the same box? I'm not talking about this FreeRADIUS box you gave logs from, I'm talking about the box thats got thatIP address in your logs. THATS the system you need to be checking older FreeRADIUS had many issues - 1.1.6 is ancient and I wont be spending any time on this mailing list supporting it. 2.1.x is where its at. alan
Same box. On Mon, Apr 27, 2009 at 4:57 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Accounting server was alive and receving packets till yesterday. And suddenly got receiving dead alive messages. So restarted radiusd process then it got resolved.
are we talking about the same box? I'm not talking about this FreeRADIUS box you gave logs from, I'm talking about the box thats got thatIP address in your logs. THATS the system you need to be checking
older FreeRADIUS had many issues - 1.1.6 is ancient and I wont be spending any time on this mailing list supporting it. 2.1.x is where its at.
alan
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Same box.
and you do live accounting database insertions? This sounds to me very much like the classic 'tables have now grown just too big' - everything works fine then barfs one day. the request isnt getting serviced in time therefore its marking as dead..check your query times...remove wrong/unused indexes or move to 'out of band' accounting inserts - very easy with 2.1.x alan
Hi, As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/ python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down. On 27.04.2009, at 15:41, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Same box.
and you do live accounting database insertions? This sounds to me very much like the classic 'tables have now grown just too big' - everything works fine then barfs one day. the request isnt getting serviced in time therefore its marking as dead..check your query times...remove wrong/unused indexes or move to 'out of band' accounting inserts - very easy with 2.1.x
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Borislav Dimitrov -
Ivan Kalik -
Nicolas Goutte -
ramesh p