You can use netstat to see current socket usage. Make sure GnuGk process
does not hit any OS specific per process handle limit, check top command
and GnuGk memory usage. Try to use smaller RTPPortRange (do you really
need 50.000 ports?). If your process is going to use more than 1024 file handles,
you need to compile GnuGk with LARGE_FDSET option enabled.
Try to check errno.h file for description of errno code 24 and check 'man bind'
to find possible causes (bind system call fails in this case).
----- Original Message -----
From: "Bahram S. Biria" <bsbiria@xxxxxxxxxxxxx>
Sent: Monday, January 16, 2006 11:44 PM
The following thread was opened back to late November. To refresh your mind, I had a problem with version 2.2.1. It was freezing
after a while with no chance of getting into the status port using Telnet.
I was told that probably it is a socket issue and was recommended to use version 2.2.3-2 because it has a better socket management.
At the time version 2.2.3-2 was causing call drops with cause code 41 and that's why I preferred to use the 2.2.1.
Finally I was frustrated and decided to use the version 2.2.3-2 to not experience the freezing problem again. Unfortunately, the
version 2.2.3-2 has also the same symptom and would freeze after a while. The only good thing is that this version will provide more
information in the log which might help to understand what the cause could be .
I could see a bunch of unpleasant error messages through the log and if I bring them all up here it would be more confusing than
helpful so I'd provide two of them here for now.
The following is one of these error messages which most probably has a close connection with the problem.
2006/01/15 07:20:39.701 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:3930 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:39.701 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:3932 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:39.701 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:3934 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:39.701 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:3936 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:39.701 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:3938 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:39.701 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:3940 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:39.701 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:3942 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:39.701 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:3944 not available - error 7/24: Cannot allocate
memory
There were about 7500 of this message until reaching to the following part of the log.
2006/01/15 07:20:45.202 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:49928 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:45.202 1 ProxyChannel.cxx(3059) RTP RTP socket 0.0.0.0:49930 not available - error 7/24: Cannot allocate
memory
2006/01/15 07:20:45.202 2 ProxyChannel.cxx(3076) RTP Logical channel 0 could not be established - out of RTP sockets
2006/01/15 07:20:45.202 1 ProxyChannel.cxx(3613) Proxy Error: Can't create fast start logical channel id 1
2006/01/15 07:20:45.204 1 ProxyChannel.cxx(2316) Q931d Could not open/connect Q.931 socket at xxx.xxx.xxx.xxx:0 - error
7/24: Cannot allocate memory
2006/01/15 07:20:45.204 3 ProxyChannel.cxx(2328) Q931 yyy.yyy.yyy.yyy:1720 DIDN'T ACCEPT THE CALL
Most probably the developers know in what condition this might happen and give me a clue about the remedy.
To give you an idea, the GNUGK was running on a double Xeon with 1G memory and the maximum number of connected sessions was about
100 so the amount of available memory or lack of cpu time shouldn't be the case.
I also could see the following error message as well which might be interesting.
2006/01/15 06:20:57.339 0 assert.cxx(108) PWLib Assertion fail: Operating System error, file tlibthrd.cxx, line 746,
Error=24
Maybe this error message shed a light on what the problem is.
Regards,
Bahram.
----- Original Message -----
From: Zygmuntowicz Michal
To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Sent: Thursday, November 24, 2005 3:01 PM
Subject: Re: Could we call this a CRASH?
Maybe your accounting/authentication modules slow down.
Also make sure you have CallSignalHandlerNumber set to something
greater than 1.
----- Original Message -----
From: "Bahram S. Biria" <bsbiria@xxxxxxxxxxxxx>
Sent: Thursday, November 24, 2005 8:41 PM
I retested with version 2.2.3-2 but as before this version was killing most of the calls with dcc 41. So, I couldn't get to the
point to see if the freezing problem would happen with this version.
All the timers that were available in the [RoutedMode] section were increased for retest and it didn't change anything. I am not
sure if reading and setting this timers should have been written in the logs since I didn't see anything. Please let me know if it
is supposed to be shown in the logs then I would know that I didn't set them properly.
I increased the fdset number from 4096 to 32768 and again it didn't change anything. The version 2.2.1 froze even with the higher
number of fdset. The maximum no of calls on the GNUGK was about 50 and I am not sure if lack of socket with this number of
concurrent calls is something to think about !
The OS that I am using is RedHat 9. If there is something else that I should do to increase the number of sockets beside
increasing
the fdset and in OS level, please let me know and I'll go for it.
Thanks,
Bahram.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/
