FR behavior when DB not available

[Anatoliy]

Hi Alan, there are 2 options how DB can fail.
  1) application fail, in this case host os will reply with icmp port
unreachable, which should help with faster detection that DB failed
  2) Host(where DB running ) failed, of network problem between radius and
DB, in this case we will not receive any reply . And I am reproducing this
scenario, by blocking incoming tcp packets from port 1521 (oracle) .

On Mon, Jul 17, 2023 at 5:53 PM Alan DeKok <aland at deployingradius.com>
wrote:

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