RADIUS failing to start correctly when remote DB is unavailable.

[Alan DeKok]

On Oct 11, 2022, at 9:38 AM, Sea Gull <seagull0044 at gmail.com> wrote:
> Good afternoon! I have a setup where RADIUS is set to write to multiple DBs
> simultaneously. I have set this as follows:
> 
> 1. Copied the SQL instance in /etc/raddb/mods-enabled/sql and had it
> renamed and configured accordingly.
> 2. Called them both
> 3. In the pool, I have set start=0
> 4. Set read_client to no

  OK...

> Although from debug these seem to be correctly set, I am still getting the
> message that RADIUS is trying to connect to the DB when it is unavailable.

  That's how it works.

  The only way that FreeRADIUS knows that the DB is unavailable is by trying to connect, and failing.

> After quite a number of minutes and 3 retries, RADIUS fails to start. I
> have attached the full debug and included some explanation too along the
> way.

  The debug log shows that it's starting fine.  And that it's trying to connect to the SQL server when FreeRADIUS receives accounting packets.  Because that's what you configured FreeRADIUS to do.

  If you want it to dynamically choose an SQL server based on which one is up, you can put them into a redundant section:

	redundant {
		sql1
		sql2
	}

  That will choose sql1 until it's down, and then will choose sql2.  But it will still try to use sql1, because FreeRADIUS has no idea that it's down.  There's no magical connection between SQL and FreeRADIUS which says "SQL database is down".

  So the server does start, and it works as documented, and it works the only way it *can* work.  I'm not sure what else you expect it to do here.

  My recommendation is that if FreeRADIUS is using a DB, then you should ensure that the DB is up 100% of the time.  All of the fail-over, redundant, etc. checks in the server are there only to catch unusual / error cases.  If your SQL server is *normally* down, then just configure FreeRADIUS to not use it.

  Alan DeKok.