-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIP Websocket accept queue fills up - FS does not accept new connections any more #922
Comments
For debugging purposes I created a file every minute containing the output of /opt/freeswitch/bin/fs_cli -x "show channels"|tee -a "$file"
netstat -putan | grep -i "7443\|5066\|5060"|tee -a "$file" when I grep | wc these files for CLOSE_WAIT, I can see that the number of CLOSE_WAIT connections is piling up:
In the freeswitch log there is nothing obvious indicating a problem. Is there anything I should look for? |
In the meantime there is some new information in the mentioned BBB issue that might help getting the root cause of this. So I will quickly summarize here:
So chances are that this is a bug in freeswitch's handling of ssl connections. |
Same behaviour HERE. Exactly the same description and system stop answer socket connection at 64 CLOSE_WAIT.
I think it's FS side too because if we connect directly to the port to check certificate expiration date, the connexion doesn't work and nothing answer.
I see the incoming request coming to the host via tcpdump but no answer from FS then, I tried to stop and start profile internal. And then, openssl works too.
|
Same behaviour HERE,Is it really solved in this way? |
This still seems to be happening - the WSS socket seems to stop reading from the socket.. see: freeswitch/sofia-sip#177 |
I have been able to reproduce the issue a little more reliably tonight. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name The Recv-Q gets to 1 plus and the websocket thread stops... I have to restart FS to correct. the webphones, using WSS are done - FS is simply not receiving the packets. I'm wondering if there is some buffer overflow happening... That'll have to wait a few days |
A moment ago, FS stopped talking to the IPv4 clients (5060/7080/7443) The ESL (8021) and the IPv6 ports seem OK. I got some 1006 errors on the javascript side... I waited 10 minutes but it did not correct itself. Wed 05 Oct 2022 09:53:37 AM EDT Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 27 0 [IP v4]:7080 0.0.0.0:* LISTEN 25442/freeswitch tcp 15 0 [IP v4]:5060 0.0.0.0:* LISTEN 25442/freeswitch tcp 65 0 [IP v4]:7443 0.0.0.0:* LISTEN 25442/freeswitch tcp 0 0 0.0.0.0:8021 0.0.0.0:* LISTEN 25442/freeswitch tcp6 0 0 [IP V6]:5060 :::* LISTEN 25442/freeswitch tcp6 0 0 [IP V6]:7443 :::* LISTEN 25442/freeswitch This is with the latest libsofia-sip-au lib 1.13.9 |
does anyone have FS 1.10.6 with the latest libsofia-sip-au and ctxSIP working over WSS ? |
we have exactly the same issue with FS 1.10.6 and libsofia 1.13.9 with WSS handled by FS we do not have any solution for the moment :( |
someone has experienced this issue with the latest release of FS ? is it solved in this ? |
I confirm that the problem is still there. |
hi, confirm the same problem, may this can help,
|
Hey there are you willing to share your nginx config?Sent from my Galaxy
-------- Original message --------From: "Jovany Leandro G.C" ***@***.***> Date: 2023-03-21 12:12 PM (GMT-05:00) To: signalwire/freeswitch ***@***.***> Cc: Jerry ***@***.***>, Comment ***@***.***> Subject: Re: [signalwire/freeswitch] SIP Websocket accept queue fills up - FS does not accept new connections any more (#922)
hi, confirm the same problem, may this can help,
you can see the close-wait between nginx <-> freeswitch (7480)
FreeSWITCH (Version 1.10.8 -release.14 64bit) is ready
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:58386
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:58378
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:41654
CLOSE-WAIT 586 0 127.0.0.1:7480 127.0.0.1:38728
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:45936
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:58394
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:42686
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:53894
CLOSE-WAIT 1 0 10.81.83.199:45260 pbx2:80
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:59428
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:35354
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:57752
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:38542
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:58390
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:37448
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:52484
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:54714
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:53708
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:45924
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:56326
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:56338
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:39284
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:57398
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:54702
CLOSE-WAIT 1 0 10.81.83.199:42490 pbx2:80
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:42672
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:47056
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:55326
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:35382
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:50532
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:46972
CLOSE-WAIT 554 0 127.0.0.1:7480 127.0.0.1:55412
CLOSE-WAIT 554 0 127.0.0.1:7480 127.0.0.1:42674
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:57382
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:39046
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:52456
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:34092
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:36612
CLOSE-WAIT 554 0 127.0.0.1:7480 127.0.0.1:40546
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:42556
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:46974
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:50526
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:58404
CLOSE-WAIT 554 0 127.0.0.1:7480 127.0.0.1:52452
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:42942
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:39288
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:38732
CLOSE-WAIT 554 0 127.0.0.1:7480 127.0.0.1:35370
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:57808
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:53724
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:52468
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:46150
CLOSE-WAIT 586 0 127.0.0.1:7480 127.0.0.1:57770
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:45720
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:45948
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:57764
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:50486
CLOSE-WAIT 613 0 127.0.0.1:7480 127.0.0.1:55400
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:38538
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:55320
CLOSE-WAIT 1 0 10.81.83.199:46320 pbx:80
CLOSE-WAIT 1 0 10.81.83.199:45886 pbx:80
CLOSE-WAIT 225 0 127.0.0.1:7480 127.0.0.1:46134
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:41834
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:59558
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:45958
CLOSE-WAIT 552 0 127.0.0.1:7480 127.0.0.1:57812
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Hi |
This can probably be closed, duplicate of #2283 |
Fixed by freeswitch/sofia-sip#233 |
Describe the bug
FS runs in a BigBlueButton setup behind a nginx reverse proxy. Connections are made through sofia websocket.
There are 65 connections between nginx and FS in CLOSE_WAIT state on the Freeswitch side of the connection. This did not change after a few hours. To my knowledge this means that connections are not correctly closed by Freeswitch. At the same time the TCP accept queue seems to be full:
This leads to an unresponsive freeswitch. New connections using Sip over websocket are impossible. Connections to the event socket are possible.
To Reproduce
Unfortunately this problem occurs only on rare conditions, I do not know what is neccesary to reproduce this. However this problem is not a singular event, I observed it a few times in the past and other BigBlueButton users observed this as well. See bigbluebutton/bigbluebutton#9667
I created a core dump and extracted a stack trace.
Expected behavior
Freeswitch should serve websocket requests.
Package version or git hash
Trace logs
Provide freeswitch logs w/ DEBUG and UUID logging enabled
backtrace from core file
I keep the core file, sources and binary from Freeswitch, let me know if I can provide anything to help to track this down. Thank you.
The text was updated successfully, but these errors were encountered: