(RADIATOR) SQL Timeout vs SQL "Could not Connect"

Mon Oct 21 09:07:38 CDT 2002

Hello Chris -

It sounds like Perl is crashing for some reason.

Can you run radiusd from the command line and see what is printed as 
the error message from Perl?

	perl radiusd -foreground -log_stdout -config_file .....

regards

Hugh

On Monday, October 21, 2002, at 11:17 PM, Chris Cronje wrote:

> Hi Hugh
>
> If I'm not mistaken, we are using:
>
> Perl Version 5.6.1
> DBI - Version 1.30
> DBD - Oracle version 1.12
> Oracle Version 9i
>
> Running on Red Hat Linux 7.3 on Intel Platform.
>
> By "shut down immediately" I mean the following:
>
> Radiator displays this message in the logfile:
>
>> Mon Oct 21 14:11:22 2002: ERR: do failed for 'delete from RADONLINE
>> where NASIDENTIFIER='196.2.129.13' and NASPORT=0': SQL Timeout
>
> Immediately after this radiusd is not running as a process anymore. I 
> dont see any additional errors or anything, radiusd is just not there 
> anymore.
>
> Thanks
>
> Chris
>
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: 21 October 2002 02:51
> To: Chris Cronje
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) SQL Timeout vs SQL "Could not Connect"
>
>
>
> Hello Chris -
>
> Could you please clarify what you mean by "shuts down immediately"?
>
> And could you also please send me all the details regarding
> hardware/software platform, versions of Perl, DBI, DBD, Oracle, etc.
> Radiator should back off from the database for the specified time and
> then try to reconnect.
>
> regards
>
> Hugh
>
>
> On Monday, October 21, 2002, at 10:33 PM, Chris Cronje wrote:
>
>> Hi There
>>
>> (Radiator 3.3.1)
>> I have a question about the Timeout and FailureBackoffTime settings
>> used for SQL connections. Specifically for the Sessiondatabase
>> configuration I am using below:
>>
>> <SessionDatabase SQL>
>>         DBSource        dbi:Oracle:TEST
>>         DBUsername      radiator
>>         DBAuth          radiator
>>         Timeout 3
>>         FailureBackoffTime 60
>> </SessionDatabase>
>>
>>
>>
>> If there is no existing SQL connection and Radiator cannot connect to
>> the SQL Database at all, a "Could not connect" message is generated
>> and Radiator backs off for 60 seconds as specified:
>>
>>
>>
>> Mon Oct 21 14:09:50 2002: DEBUG: Packet dump:
>> *** Received from 196.2.129.13 port 1572 ....
>> Code:       Access-Request
>> Identifier: 0
>> Authentic:        1035202501
>> Attributes:
>>         User-Name = "modtest"
>>         User-Password = "Z?<201>1<188><142>+<159>c<190>O+<21>M<180>t"
>>
>> Mon Oct 21 14:09:50 2002: DEBUG: Handling request with Handler 
>> 'Realm='
>> Mon Oct 21 14:09:53 2002: ERR: Could not connect to SQL database with
>> DBI->connect dbi:Oracle:TEST, radiator, radiator: timeout at
>> /usr/lib/perl5/site_perl/5.6.1/Radius/Util.pm line 519.
>>
>> Mon Oct 21 14:09:53 2002: ERR: Could not connect to any SQL database.
>> Request is ignored. Backing off for 60 seconds
>>
>>
>>
>>
>> If there is an existing SQL session and a network failure occurs,
>> Radiator generates an "SQL Timeout" message, as opposed to the "Could
>> not connect" from above. In this case, Radiator does not seem to do
>> the Failure Backoff, in fact it actually shuts down immediately after
>> the SQL Timeout error:
>>
>>
>>
>>
>> Mon Oct 21 14:11:19 2002: DEBUG: Packet dump:
>> *** Received from 196.2.129.13 port 1582 ....
>> Code:       Access-Request
>> Identifier: 10
>> Authentic:        1035202591
>> Attributes:
>>         User-Name = "modtest"
>>         User-Password =
>> "{<225>.<213><171>y<223><175><249><24>d<7>)<135><130>/"
>>
>> Mon Oct 21 14:11:19 2002: DEBUG: Handling request with Handler 
>> 'Realm='
>> Mon Oct 21 14:11:19 2002: DEBUG:  Deleting session for modtest,
>> 196.2.129.13,
>> Mon Oct 21 14:11:19 2002: DEBUG: do query is: delete from RADONLINE
>> where NASIDENTIFIER='196.2.129.13' and NASPORT=0
>>
>> Mon Oct 21 14:11:22 2002: ERR: do failed for 'delete from RADONLINE
>> where NASIDENTIFIER='196.2.129.13' and NASPORT=0': SQL Timeout
>>
>>
>>
>> Is this the way it is supposed to be or should the FailureBackoffTime
>> work for both "Could Not Connect" and "SQL Timeout" conditions ?
>>
>>
>>
>> Kind Regards
>>
>> Chris Cronje
>>  
>> Give your child an unfair advantage with M-Web Learning.  To join,
>> call 08600 32 000 or go to http://join.mweb.co.za
>>
>> M-Web – JUST LIKE THAT
>> ===
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
>>
>>
>
> NB: I am travelling this week, so there may be delays in our
> correspondence.
>
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: I am travelling this week, so there may be delays in our 
correspondence.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.