[RADIATOR] radiator exists on ClientSQL timeout

Wed May 25 11:09:12 CDT 2011

Hi Heikki,
no, this is only acting as tacacs+ server without any db logging.

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

-Alex

Am 2011-05-25 17:37, schrieb Heikki Vatiainen:
> On 05/24/2011 05:06 PM, Alexander Hartmaier wrote:
>> Since changing the init script line 37 from:
>> [ -z "${RADIUSD_ARGS}" ]&&  RADIUSD_ARGS="-config_file $RADIATOR_CONFIG
>> -daemon $RADIATOR_ARGS"
>> [ -z "${RADIUSD_ARGS}" ]&&  RADIUSD_ARGS="-config_file $RADIATOR_CONFIG
>> $RADIATOR_ARGS -foreground -log_stdout>  /var/log/radiator/stdout.log
>> 2>/var/log/radiator/stderr.log"
>>
>> it doesn't crash any more but still hangs after log entries like:
>> Tue May 24 15:54:34 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': ORA-03114: not connected to ORACLE (DBD ERROR:
>> OCIStmtExecute/Describe)
> Hmm, connection was lost. I previously asked if you do LogSQL. If you
> do, then change SQL log config so that LogSQL and ClienetListSQL use
> different usernames (DBUsername) for DB access. When you do this,
> ClientListSQL and LogSQL will get their own handles and connections.
>
> What may happen now is ClientListSQL tries to log "Adding Clients ...",
> which is given to LogSQL which notices closed connection and destroys
> the handle.
>
> Then control returns to ClientListSQL and it continues and tries to read
> from the handle which was just killed by LogSQL.
>
> There is actually a comment on this now in 4.8 ref.pdf. See section
> 5.14.1. It was noticed when LogSQL runs in parallel with other SQL users
> it is possible that it can close DB handles when other DB users do not
> expect it.
>
> Please let us know if seprate LogSQL user solves the problem.
>
>
>> Am 2011-05-18 10:45, schrieb Hartmaier Alexander:
>>> Hi,
>>> I was referring to the MaxChildren config option which we don't use.
>>>
>>> Add the -b option to start-stop-daemon and replacing -daemon with
>>> -foreground did the trick.
>>>
>>> It occurs approximatly once per day, maybe a Monday-morning bug.
>>>
>>> Best regards, Alex
>>>
>>> Am 2011-05-16 23:02, schrieb Heikki Vatiainen:
>>>> On 05/16/2011 08:33 PM, Alexander Hartmaier wrote:
>>>>> I haven't configured forking so we should be safe.
>>>> Sorry, I may have been a bit unclear about which fork I was meaning.
>>>> When Radiator is started without --foreground it will fork. If Fork has
>>>> been configured for an AuthBy, Radiator will fork an additional copy to
>>>> handle that authentication.
>>>>
>>>> What is important that there are no forks, not even the initial fork
>>>> when Radiator backgrounds itself.
>>>>
>>>> If possible, can you send your configuration file. If not possible, I
>>>> would like to know if you are using<Log SQL>.
>>>>
>>>> If you are, try creating another username that Log SQL uses for
>>>> accessing the DB. This will give SQL logging another DB handle which may
>>>> help. This is mentioned in 4.8 ref.pdf
>>>>
>>>>> Am 2011-05-16 19:05, schrieb Heikki Vatiainen:
>>>>>> On 05/16/2011 07:58 PM, Alexander Hartmaier wrote:
>>>>>>> My init file is from the goodies dir.
>>>>>> Ok, then we have to work around Debian specific things a bit.
>>>>>>
>>>>>>> Because I'm running debian the command used is
>>>>>>> /sbin/start-stop-daemon --start --pidfile /var/run/radiusd.pid --exec
>>>>>>> $RADIUSD -- $RADIUSD_ARGS
>>>>>>>
>>>>>>> where $RADIUSD_ARGS is the default of -config_file $RADIATOR_CONFIG
>>>>>>> -daemon $RADIATOR_ARGS
>>>>>>>
>>>>>>> I've now changed it to:
>>>>>>>      -z "${RADIUSD_ARGS}" ]&&     RADIUSD_ARGS="-config_file $RADIATOR_CONFIG
>>>>>>> -daemon $RADIATOR_ARGS -log_stdout>     /var/log/radiator/stdout.log
>>>>>>> 2>/var/log/radiator/stderr.log"
>>>>>>>
>>>>>>> The -foreground option isn't compatible with start-stop-daemon but I
>>>>>>> hope -log_stdout is compatible with -daemon too.
>>>>>> That may not work since -foreground keeps Radiator from forking and
>>>>>> closing stdout. In other words, -foreground is needed for catching all
>>>>>> messages. Would it be possible to do the following:
>>>>>>
>>>>>> 1. Start Radiator with unmodified start script
>>>>>> 2. Observe what the actual command is (radiusd + all arguments)
>>>>>> 3. Run radiusd from command line with the observed arguments plus
>>>>>> -foreground and -log_stdout
>>>>>>
>>>>>> Thanks again!
>>>>>>
>>>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>>>>
>>>>> 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
>