FR behavior when DB not available

[Anatoliy]

Hi Alan , thank you for fast response, Unfortunately , I am really bad in
programming , and freeradius will be better without my patches ...
Now I am trying to better understand FR logic, When blocking tcp connection
with DB , I just want to test scenario when DB  down (for MW of due to some
issue)

So sql query always block core thread, and only option is to find way for
faster detect that tcp session to DB fails ? For example max_retries option
introduced in 3.2.3.
But I think that retry_delay option should prevent all threads from
connecting to DB for some time, if previous connection is fails. And these
messages tells about this , or my understanding is wrong ? Increasing
retry_delay should help faster reply to NAS with Access-Accept.
      Warning: rlm_sql (sql): Cannot open a new connection due to rate
limit after failure

On Mon, Jul 17, 2023 at 7:20 AM Alan DeKok <aland at deployingradius.com>
wrote:

> 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.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>