FR behavior when DB not available

[Alan DeKok]

On Jul 16, 2023, at 10:22 PM, Anatoliy <cphlpd at gmail.com> wrote:
> 
> 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)

  The solution here is to make sure that your database stays up.  Plus, "TCP connection blocked" is NOT the same as "database is down".

  When the database is down, existing TCP connections are closed, and new connections are refused.  FreeRADIUS handles this situation well.

  When the TCP connections are blocked as in your example, there are very few ways to recover from it.  As I said, many SQL client libraries are not asynchronous.  Which means that FreeRADIUS calls the library, and the library tries to connect to the SQL server.  If the SQL server (or TCP connection) blocks, then so does the library, and so does FreeRADIUS.

  There is pretty much nothing that we can do to fix that.  We are *not* going to write our own non-blocking SQL client library.  It's hard enough to write a RADIUS server.

> So sql query always block core thread, and only option is to find way for
> faster detect that tcp session to DB fails ?

 Read my previous message again.  I answered this.  My answer won't change if you keep asking the question.


> 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.

  I think I want a pony for my birthday.  That's a nice thought.  But it's not realistic.

> And these
> messages tells about this , or my understanding is wrong ? Increasing
> retry_delay should help faster reply to NAS with Access-Accept.

  No.

  The server configuration is well documented.  The "retry_delay" options is well documented.  And it's *not* documented as "causing a faster reply to the NAS".

  I really don't know how to make the documentation any more clear.  I'm not sure why you're reading it, and concluding that "retry_delay" does something completely different from what the documentation says.

  Stop wasting your time trying to say how FreeRADIUS "should" work.  There are a lot of complex issues involved.  You need to understand all of those issues before having an informed opinion on what "should" happen.  It's also difficult to have an informed opinion if the existing documentation is misinterpreted.

  Alan DeKok.