[RADIATOR] ActiveState Win32 and FailureBackoffTime

Robert Fisher robert at sitestar.net
Tue Jul 30 13:33:08 CDT 2013


OK...Upgraded from ActivePerl 5.8 to 5.16 as well as making sure all the
relavent packages were updated as well and updated Radiator from 3.14
to 4.11 -- but I'm still not seeing a reconnect attempt if the service loses
connectivity.   So apparently I missed something -- can someone spot what
that might be?   Here's a cleaned up snippet from a Trace 3 log (far too 
much
traffic to sit with Trace 4) and the relevant parts of my config.   As 
you can see,
I'm definining the FailureBackOffTime in my ClientListSQL and in the AuthBy
clause (AuthBy Sitestar is essentially a customized AuthBy EMERALD module
which still inherits the DB connection parameters from AuthBy SQL...I 
also use
some AuthBy SQL clauses with the same parameters as well) -- and then in
addition to defining the FailureBackOffTime -- I also define the 
RefreshPeriod
of the ClientListSQL -- but the log shows 'backing off for 0 seconds' 
and never
indicates an attempt to reconnect.

Tue Jul 30 13:50:59 2013: ERR: Could not connect to SQL database with 
DBI->connect dbi:ODBC:RADIUSDB, raduser, raddbpass:  [Microsoft][ODBC 
SQL Server Driver]Timeout expired (SQL-HYT00)
Tue Jul 30 13:50:59 2013: ERR: Could not connect to any SQL database. 
Request is ignored. Backing off for 0 seconds
Tue Jul 30 13:51:00 2013: NOTICE: Server started: Radiator 4.11 on freedom


# Let's define several variables.
DefineGlobalVar    SUBSCRIBER_DB    dbi:ODBC:RADIUSDB
DefineGlobalVar ACCOUNTING_DB    dbi:ODBC:RadiusAcct
DefineGlobalVar PROPELACCT_DB    dbi:ODBC:RadiusAcct
DefineGlobalVar    databaseuser    raduser
DefineGlobalVar    databasepass    raddbpass

DefineGlobalVar    databackofftime    300


<ClientListSQL>

         DBSource            %{GlobalVar:SUBSCRIBER_DB}
     DBUsername        %{GlobalVar:databaseuser}
         DBAuth              %{GlobalVar:databasepass}
     FailureBackoffTime    %{GlobalVar:databackofftime}

     # Re-read Servers table every 15 minutes.
     RefreshPeriod        900

     GetClientQuery        SELECT \
         IPAddress AS NASIdentifier, \
         Secret, \
         NULL AS IgnoreAcctSignature, \
         DupInterval, \
         DefaultRealm, \
         NasType, \
         Community AS SNMPCommunity, \
         NULL AS LivingstonOffs, \
         NULL AS LivingstonHole, \
         NULL AS FramedGroupBaseAddress, \
         NULL AS FramedGroupMaxPortsPerClassC, \
         RewriteUsername, \
         NoIgnoreDuplicates, \
         NULL AS PreHandlerHook, \
         Comments AS Identifier, \
         DefaultReply, \
         NULL AS FramedGroup, \
         StripFromReply, \
         AllowInReply, \
         AddToReply, \
         AddToReplyIfNotExist, \
         DynamicReply, \
         AddToRequest, \
         StripFromRequest, \
         AddToRequestIfNotExist, \
         Flags \
         FROM Servers

</ClientListSQL>

<AuthLog FILE>
     Identifier    sitestar-log
     Filename    %L/rad-auth-%Y-%m.log
     LogSuccess    1
     LogFailure    1
     SuccessFormat    %l:%c:%N:%u:%U:%P:%1:OK
     FailureFormat    %l:%c:%N:%u:%U:%P:%1:FAIL
</AuthLog>



<AuthBy SITESTAR>

     Identifier    SitestarAuth

     DBSource        %{GlobalVar:SUBSCRIBER_DB}
     DBUsername    %{GlobalVar:databaseuser}
     DBAuth          %{GlobalVar:databasepass}

     FailureBackoffTime    %{GlobalVar:databackofftime}

     AuthSelect    RadUserLookup '%U', '%R', '%{Request:Called-Station-Id}'

     # Empty AccountingTable turns off Accounting.
     IgnoreAccounting
     AccountingTable

     CaseInsensitivePasswords
     AddATDefaults
</AuthBy>


<Handler>
     AuthLog        sitestar-log
     AuthBy        SitestarAuth
</Handler>

Robert Fisher
Systems Administrator
Sitestar Internet Services


On 7/23/2013 9:01 AM, Robert Fisher wrote:
> Hrmm -- Don't have a trace 4 log, but did see where the logs have a
> backing off
> for 0 seconds, and my ClientListSQL clause has a refresh of 900 -- but
> it's still
> not triggering a reconnect, though I do notice I'm running a rather old
> version
> of 3.14 -- so going to try updating Perl and Radiator before continuing
> to tweak
> settings.
>
> Robert Fisher
> Systems Administrator
> Sitestar Internet Services
>
>
> On 7/23/2013 5:43 AM, Sami Keski-Kasari wrote:
>> Hello Robert,
>>
>> On 07/22/2013 05:59 PM, Robert Fisher wrote:
>>
>>> Even though I have the FailureBackoffTime defined to 300 or 5 minutes,
>>> it seems to be ignored.
>> It is supported on windows. FailureBackoffTime applies when none of
>> the configured DBs can be connected. The next connection attempt is
>> done when the FailureBackoffTime has elapsed.
>>
>> Can you see "Backing off for aaaaa seconds messages" in the log?
>>
>> Could you reply with trace 4 logfile from this event?
>>
>>> The documentation does state the optional Timeout
>>> parameter is ignored on ActiveState Win32, and I suspect that has more
>>> to do with the level of control of TCP sockets in Win32 more than
>>> anything
>>> else.
>> True, Timeout is ignored and the command runs as long as it returns
>> for some reason. The reason it is ignored has to do with how signals
>> are implemented in Win32 perl.
>>
>>> What I don't understand is why the FailureBackoffTime doesn't cause
>>> Radiator to attempt a reconnect, and can see there's no second attempt
>>> to reconnect because nothing new about the connection makes it into
>>> the logs 5 - 10 - 15 minutes or even hours after the event until the
>>> service/daemon is restarted.
>> If there is activity that requires DB access and there is currently no
>> connection to the DB, it should reconnect. Note that if you have e.g.,
>> ClientListSQL with no refresh, there is only one attempt to fetch the
>> client list. If that fails, then no retries are done. You can
>> configure a refresh interval that should make periodic connections.
>>
>>> So my questions are:
>>>
>>>
>>> 1)   Is some extra step required to use FailureBackoffTime in Windows?
>> No
>>
>>> 2)    Alternatively, is there any way to hook into the connection lost
>>> as an event so I can kill the radiator instance -- since that would at
>>> least be able to signal to Windows that the service has "died" and
>>> can then use the MS tools to try and restart the service and thus
>>> resynch the connection.
>> There is currently undocumented hook that is called when no databases
>> can be connected to. Currently the hook just logs the above "Backing
>> off..." massage and does nothing else.:
>> ConnectionAttemptFailedHook (see SqlDb.pm).
>>
>> Best Regards,
>>   Sami
>>
>>
>>
>>
>>
>>> Thanks in advance,
>>>
>>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


More information about the radiator mailing list