[RADIATOR] Accounting process dying

[Jim]

Heikki Vatiainen wrote:
> On 01/27/2011 05:48 PM, Jim wrote:
>
>   
>> We are running separate processes for Radius accounting and 
>> authentication, and each is running with 'FarmSize 4'.  For the 
>> accounting I'm seeing:
>>
>> Thu Jan 27 15:04:57 2011: WARNING: Server farm process 31432 died, 
>> restarting
>> Thu Jan 27 15:04:57 2011: DEBUG: Forking server farm instance 1
>>     
>
> Thanks for your report.
>
> Can you tell more about your operating environment? What is your
> Radiator version, does it have patches, what is your operating system,
> is it 64bit or 32bit, what is the load level when you see restarts, is
> the memory usage starting to reach system limits etc.
>
> If you are running Linux, does dmesg command show anything special e.g.,
> out of memory messages? Do system logs show anything peculiar from the
> time the crash happens?
>   
We are running Radiator 4.4 & 4.5.1 on 32bit Redhat ES3.  Nothing 
unusual shows in the logs and memory appears to be fine.  The servers 
have 2Gb memory and only running Radiator.


>> The logfile for instance 1 at Trace 4 doesnt show any errors around this 
>> time, the last thing in the log was a SQL update at ('Thu Jan 27 
>> 15:04:51 2011: DEBUG: do query is: 'UPDATE.....').  How can I see what 
>> is causing this process to die?  I suspect its related to the SQL 
>> updates in some way as the authentication process doesn't suffer this 
>> issue and doesn't log anything to SQL.
>>     
>
> If you already have Trace 4 enabled and there is nothing in logs, it is
> hard to say. As I wrote above, can you tell e.g., if you are not running
> out of memory when the process dies.
>
>   
>> Is it possible to either include the process ID in the logfile name, or 
>> within the logging itself so that I can easily see where and when a 
>> process has stopped and what the last accounting action was?
>>     
>
> Currently there is no such method. If you take a look at Radius/Log.pm
> and sub main::log function, you could add this
>
> $s = "PID:$$ $s";
>
> just before the comment "Catch recursion".
>
> After that all log messages will contain the process ID.
>
>   
Thanks that's was very useful.  I have done some more debugging and its 
apparent that whenever the process dies the last thing it was doing was 
a SQL update to a MS-SQL server.  Doing some digging and it looks like 
we are connecting to MS-SQL via Freetds.

Radiator connection:
        Identifier      MSSQL-SessionDB
        DBSource        dbi:Sybase:MSDBServerX
        DBUsername      dbuser
        DBAuth          dbpassword
        Timeout         5

/usr/local/freetds/etc/freetds.conf:
    [MSDBServerX]
        host = x.x.x.x
        port = 1433
        tds version = 7.0

I think the FreeTDS version we have maybe to recent as its newer than 
the FAQ recommends - although the FAQ says "As of September 2003..".  
What is the best way, if there is one, to connect to a Windows MS-SQL 
2008 server?

Thanks.

Jim.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20110128/48011ce8/attachment-0001.html