Hibernating: Major impact on authentication!

Kenneth Marshall ktm at rice.edu
Tue Feb 6 03:06:30 CET 2007

Mr. Franco,

I have not looked at the DB connection code, but is there a connection
timer on the DB connection. That is, does the connection get dropped
and restarted occasionally or does it persist until the connection dies?
If the latter, the problem could be that the long running connections
are not allowing the indexes and table spaces to be maintained properly.
This could cause bloat and performance problems over time. After a
restart it would clear up since now the vacuum DB maintenance process
can clear the outstanding blocks. A restart of each connection handle
every few thousand or so queries by the radius server would solve that
problem. Just an idea.


On Mon, Feb 05, 2007 at 06:30:57PM -0200, Guilherme Franco wrote:
> Hello,
> Considering that all things indicate that there might be a problem with the
> DB, I did some tweaks in PostgreSQL and took off the cron.hourly job.
> Gonna watch out for problems then, thanks!
> ---------------------------------------------------------
> Hi,
> Freeradius 1.1.4 is randomly losing connection to both databases and it's
> causing total loss in the authentication process:
> 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
> 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.
> Every time this happens, no one can authenticate and doing a restart in
> Freeradius solves the problem. To circumvent the problem, I've added a
> cron.hourly job so each hour a "service radiusd restart" is issued.
> 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. I've enabled all
> sorts of debug in the databases trying to better understand why freeradius
> is doing this, but there was no luck.
> I've installed the latest CVS and the same problem appeared, please help!

> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

More information about the Freeradius-Users mailing list