[RADIATOR] radiator exists on ClientSQL timeout

[Alexander Hartmaier]

My init file is from the goodies dir.
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.

Best regards, Alex

Am 2011-05-16 17:58, schrieb Heikki Vatiainen:
> On 05/16/2011 06:21 PM, Alexander Hartmaier wrote:
>
>> this one runs on a debian 4 vm using the distro perl version 5.8.8.
>> DBI is version 1.616, DBD::Oracle version 1.28 with instantclient
>> 11.2.0.2.0.
>> Do you have a suggestion what to add to the init script to redirect
>> those messages to a logfile?
> The radiusd arguments are -log_stdout and -foreground.
>
> Note: normally radiusd will detach from terminal and let the init script
> to finish. With -foreground option this may not happen (depends on the
> startup script) so you should should not leave the options there when
> the system boots.
>
> I would use these options from a terminal that I can leave running
> especially if there's a test server available that can be used for
> troubleshooting.
>
> If you can not run Radiator from command line, you could try starting
> Radiator with something like this:
>
> radiusd<options>  >  /var/log/radiator/stdout.log 2>
> /var/log/radiator/stderr.log&
>
> Here<options>  would contain the normal radiusd options and include
> -log_stdout and -foreground. Both stdout and stderr are directed to a
> file and&  puts radiusd to background.
>
>> Best regards, Alex
>>
>> Am 2011-05-16 14:19, schrieb Heikki Vatiainen:
>>> On 05/16/2011 02:26 PM, Alexander Hartmaier wrote:
>>>
>>> Hello Alexander,
>>>
>>>> radiator exits when encountering a sql timeout:
>>>>
>>>> Sat May 14 18:28:12 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
>>>>
>>>> I've already upgraded it from 4.7+patches to 4.8 but the problem
>>>> persists.
>>>> We had problems with tcp connections closed by an intermediate firewall
>>>> in the past without a solution.
>>>> Which logs etc. do you need from our side to troubleshoot the bug?
>>> Thanks for the report.
>>>
>>> Please tell us your operating system, perl DBI and DBD module versions
>>> and which DBD you are currently using (mysql, Pg, Oracle, etc.).
>>>
>>> If you could run Radiator with -log_stdout and -foreground radiusd
>>> options (or config file LogStdout and Foreground) and keep it running on
>>> a console where you have access to, you may be able to see what
>>> additional debug information might come from DBI, DBD or some other
>>> component.
>>>
>>> Since the libraries Radiator uses do not know about Radiator's logfile,
>>> there is a chance their messages to otherwise get lost.
>>>
>>> In many cases running with LogStdout and Foreground gives more
>>> information about the reason for exit.
>>>
>>> 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.
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>
>