Guilherme Franco wrote:
Freeradius 1.1.4 is randomly losing connection to both databases and it's causing total loss in the authentication process:
The messages you posted show it's NOT losing connection to the database.
Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Info: rlm_sql (sql_postgresql): There are no DB handles to use! skipped 0, tried to connect 0 Info: The maximum number of threads (32) are active, cannot spawn new thread to handle request
This means that ALL threads are blocked trying to access the DB, because ALL DB handles are in use. i.e. the DB is slow, and is not responding to FreeRADIUS. Fix the DB, fix the problem.
Running either in multi or single threaded mode, that messages appeared 47.099,00 times since Jan 27! Freeradius is configured with 32 max_servers and 32 connections to each DB. There's no starving since no accounting is being used and the server have to handle just 3 auths per second.
And how long does it take the server to respond to a request? If it's more than 1/3 of a second, it will quickly reach the state you see.
As this is random, it's hard to debug, but at the same time freeradius loses the connection, several other applications can successfully connect/ maintain previous established connections to the databases.
FreeRADIUS is NOT losing its connection to the DB. If you think that's happening, you will try to fix a problem that doesn't exist, and will NOT solve the real problem.
I've enabled all sorts of debug in the databases trying to better understand why freeradius is doing this, but there was no luck.
Find out why the database isn't responding to FreeRADIUS. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog