[RADIATOR] radiator exists on ClientSQL timeout

[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


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