FR behavior when DB not available

Alan DeKok aland at deployingradius.com
Mon Jul 17 01:20:15 UTC 2023


On Jul 16, 2023, at 8:45 PM, Anatoliy <cphlpd at gmail.com> wrote:
> 
> Hi Alan ,team, I am testing scenario when main DB is temporary not
> available. I set rule in iptables to block all connections to DB.

  The short answer is "don't do that".

> In this
> situation freeradius should return Accept with some parameters to NAS.

  i.e. you'd like FreeRADIUS to do that.

  What FreeRADIUS "should" do is limited by the available technologies, and time.  Not all databases have fully asynchronous APIs.  For example, MySQL added async client APIs only in 2019.

  We welcome patches to help make FreeRADIUS better.  Perhaps you could contribute?

> This part works fine, but in traffic dump I see that radius replay with big
> delay , some times upto 20-30 seconds. In log a lot messages like
> Mon Jul 17 06:12:23 2023 : Error: Unresponsive child for request 288, in
> component <core> module

  Yes.  The SQL queries are blocking.

> I am trying to tune some parameters for sql connection, but this does not
> help.

  None of the "pool" configuration items say that they help when the SQL server is blocked, or when the TCP connection between FreeRADIUS and the SQL server is blocked.

> Can you recommend which params to change to prevent freeradius stuck on sql
> connection to DB ?

  There is no magic configuration which is hidden until you ask on the mailing list.  Everything is documented extensively, most commonly in the comments in the configuration files.  If you don't see any documentation about dealign with blocked connections, then it doesn't deal with blocked connections.

> Is it possible to prevent FR trying to connect to DB for some time (i think
> it is param retry_delay ) for all threads ?

  Sure.  Send a patch to fix it.

  We're working on fixing this in v4.  But one of the reasons v4 is taking so long is that it's a very difficult problem to fix.  And also that we get very, very, few patches from people outside of the core team.

  What works well is sending patches, fixes, bug reports, etc.  What doesn't work well is "Why doesn't FreeRADIUS work the way I want?"

  It's Open Source.  If you want it to behave differently, submit a patch.  If you don't like the way it's working and don't want to submit a patch... well... we have other priorities.

  Alan DeKok.



More information about the Freeradius-Users mailing list