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.
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
