[RADIATOR] Howto investigate a "dropped connection" problem with Radiator and Postgres on a local connection?

Heikki Vatiainen hvn at open.com.au
Tue Oct 22 09:02:17 CDT 2013


On 10/22/2013 11:18 AM, Eike Lohmann wrote:

> we use <AuthBy SQL> one for authentication and another <AuthBy SQL> for 
> accounting, a never used <AuthBy File> and some <AuthBy Group>'s.
> Is this our Problem?

No, I do not think so. If you do not have Fork option anywhere, or
AuthBy EXTERNAL as you noted, the above are fine. With external, forking
and FarmSize, (do you have server farm?) one needs to be careful that
the process that requested something from the DB is the one that gets
the answer. Otherwise the messaging between Radiator processes and the
DB gets does not work correctly.

> Do you know the default value of "InactiveDestroy" we don't set it in our 
> postgres config files.

My understanding it is not set. That is, you need to explicitly set it
to true. But if you do not fork, then it should not matter.

> Never seen a retry from Radiator and we have missing START, ALIVE and STOP 
> Accounting Records in ~1% from 100.000.

When it retries you should first see an ERR message about execute
failing and then the normal DEBUG level message starting with 'Query to
...'. The DEBUG message is from the retry.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.


More information about the radiator mailing list