> On 20 Apr 2017, at 13.31, Rauno Tuul <ra...@hot.ee> wrote:
> I did a quick test on a random CentOS release 5.11 box with
> Radiator-4.11-1. Installed the rpm, changed only radius.cfg to the
> grep -v "^#" /etc/radiator/radius.cfg
> LogDir /var/log/radius
> DbDir /etc/radiator
> Trace 4
> <Client DEFAULT>
> Secret asd
> DupInterval 0
> <Realm DEFAULT>
> <AuthBy SQL>
> DBSource dbi:mysql:dbname:127.0.0.1:3310
> Timeout 1
> FailureBackoffTime 1
> DBUsername someuser
> DBAuth pointlesspassword
> AuthSelect select 'random' from nowhere
> AuthColumnDef 0, User-Name, check
> It took me an hour and a half to reproduce the issue on entirely new
> environment to Radiator without any changes on OS side.
> The problem exists with debian and centos, so it's not a distro issue.
> Please share the details about the try to reproduce the issue when the
> problem didn't occur. I really would like to know, where's the difference.
I was now able to reproduce the problem which is caused by MySQL DB driver
(libmysqlclient18 in Debian) leaving file handles open when a connect operation
is interrupted by SIGALRM signal (generic Timeout in AuthBy SQL).
You can fix it by defining a timeout value for MySQL driver in DBSource,
where the value is smaller than Timeout value used in AuthBy SQL.
Different MySQL driver options can be found from
Tuure Vartiainen <varti...@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,
radiator mailing list