[RADIATOR] radiator exists on ClientSQL timeout

[Heikki Vatiainen]

On 06/15/2011 06:07 PM, Alexander Hartmaier wrote:

> can you please give me an update on that issue?!
> We still have to restart radiator approximatly once a day because it 
> either hangs or crashes.

I took a look at some possibilities: what do you think about an option
that instructs Radiator to close the database connection after the
clientlist update? Then there would not be problems with firewall
mangling the connection. I have not discussed the option here yet, but
this is something I have thought about.

Another option for you would be to make the updates more frequent so
that the firewall does not think the TCP connection is idle.

As I wrote Radiator tries to detect and recover from unexpected
connection problems so the crash problem seems to come from lower
levels, which means debugging is much harder.

Thanks!

> Best regards, Alex
> 
> Am 2011-05-31 11:38, schrieb Hartmaier Alexander:
>> Since running with the foreground option radiator doesn't die any more
>> and the log only contains lines like those:
>> Mon May 30 17:38:14 2011: ERR: Execute failed for 'SELECT device.ipaddr,
>> 'statickey', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> NULL, NULL, device.hostid, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> 'OSC-Group-Identifier=' || tblhost.hsup FROM device JOIN
>> core.tblhost at PCMSAT01 ON (device.hostid = tblhost.hostid) WHERE
>> device.fk_collector = 5': SQL Timeout
>> Mon May 30 19:40:14 2011: ERR: Execute failed for 'SELECT device.ipaddr,
>> 'statickey', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> NULL, NULL, device.hostid, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> 'OSC-Group-Identifier=' || tblhost.hsup FROM device JOIN
>> core.tblhost at PCMSAT01 ON (device.hostid = tblhost.hostid) WHERE
>> device.fk_collector = 5': SQL Timeout
>> Mon May 30 21:42:16 2011: ERR: Execute failed for 'SELECT device.ipaddr,
>> 'statickey', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> NULL, NULL, device.hostid, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> 'OSC-Group-Identifier=' || tblhost.hsup FROM device JOIN
>> core.tblhost at PCMSAT01 ON (device.hostid = tblhost.hostid) WHERE
>> device.fk_collector = 5': SQL Timeout
>> Mon May 30 23:44:18 2011: ERR: Execute failed for 'SELECT device.ipaddr,
>> 'statickey', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> NULL, NULL, device.hostid, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> 'OSC-Group-Identifier=' || tblhost.hsup FROM device JOIN
>> core.tblhost at PCMSAT01 ON (device.hostid = tblhost.hostid) WHERE
>> device.fk_collector = 5': SQL Timeout
>>
>> Note that although the refresh interval is configured for 3600 which is
>> one hour, it only seems to try every two hours.
>>
>> Am 2011-05-30 14:02, schrieb Heikki Vatiainen:
>>> On 05/25/2011 07:09 PM, Alexander Hartmaier wrote:
>>>
>>>> no, this is only acting as tacacs+ server without any db logging.
>>> Thanks for confirming this.
>>>
>>>> # refresh the client list every hour
>>>> RefreshPeriod 3600
>>>>
>>>> The intermediate firewalls will close the connection because the tcp
>>>> connection is inactive for about an hour.
>>>> Can we enable tcp keepalives or add a check to radiator which detects
>>>> broken connections?
>>> It already does check for broken connections. Just before it prints
>>> "Adding Clients from SQL database" it does reconnect when needed.
>>>
>>> So it does a reconnect that succeeds, tries to execute the select for
>>> getting the client list and then hits "Execute failed". Now I would be
>>> interested in seeing what else it logs before it dies or hangs completely.
>>>
>>> Can you pass me the logs? I would especially be interested in seeing if
>>> it is able to log "Automatic ClientListSQL refresh failed, keeping old list"
>>>
>>>> DBIx::Connector was created from DBIx::Class code and would be the ideal
>>>> solution for this problem.
>>>> You could include the newest version with every Radiator release if the
>>>> license (same as Perl) allows it.
>>> I can ask about this, but currently disconnects and reconnects should be
>>> handled already.
>>>
>>> But if you could provide the logs that show how far Radiator gets after
>>> "Adding Clients from SQL database" that would be very useful.
>>>
>>> Thanks!
>>>
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>> T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
>> Handelsgericht Wien, FN 79340b
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>> Notice: This e-mail contains information that is confidential and may be privileged.
>> If you are not the intended recipient, please notify the sender and then
>> delete this e-mail immediately.
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


-- 
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.