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@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@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@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@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@open.com.au >> http://www.open.com.au/mailman/listinfo/radiator > _______________________________________________ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen <h...@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. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
