Alertpipe.c: read() failed: Bad file descriptor

General Help
1

there is FreePBX 15.0.16.20, Asterisk 16.9.0, installed on Hyper-V,
there is no access to the server outside, the server itself connects via nat to several SIP providers.
worked stable for several months, strange behavior happened a week ago
millions of lines of messages from the examples below began to pour into the logs, calls stopped going, reboot did not help.
saw “Connection refused” from several phones that were configured via tcp, as a nonsense I decided to change the connection to udp and everything went up, while it works well.
Here is only 100% certainty that there is no problem in tcp, it seems that it can happen again.
In the FreePBX network statistics, the graph shows scary traffic figures of 80GB send and 90GB receive.

Is there some kind of looping of rtp traffic over tcp possible and is it capable of putting Asterisk server down like that? In my opinion, one or two phones should not affect the server so much.

I ask for help, maybe someone had a similar problem

examples of logs
[2020-09-22 12:02:53] WARNING[9101][C-0000bd4d] bridge_channel.c: Weird. No frame from bridge for SIP/9999-0001c827 to process?
[2020-09-22 12:02:53] WARNING[9101][C-0000bd4d] alertpipe.c: read() failed: Bad file descriptor
[2020-09-22 12:02:53] WARNING[9101][C-0000bd4d] bridge_channel.c: Weird. No frame from bridge for SIP/9999-0001c827 to process?
[2020-09-22 12:02:53] WARNING[9101][C-0000bd4d] alertpipe.c: read() failed: Bad file descriptor

[2020-09-22 12:48:32] ERROR[3197] iostream.c: close() failed: Bad file descriptor
[2020-09-22 12:48:32] WARNING[3191][C-00000002] bridge_channel.c: Weird. No frame from bridge for SIP/9991-00000003 to process?
[2020-09-22 12:48:32] WARNING[3191][C-00000002] alertpipe.c: read() failed: Bad file descriptor
[2020-09-22 12:48:32] WARNING[3191][C-00000002] bridge_channel.c: Weird. No frame from bridge for SIP/9991-00000003 to process?
[2020-09-22 12:48:32] WARNING[3191][C-00000002] alertpipe.c: read() failed: Bad file descriptor
[2020-09-22 12:48:32] WARNING[3191][C-00000002] bridge_channel.c: Weird. No frame from bridge for SIP/9991-00000003 to process?
[2020-09-22 12:48:32] WARNING[3191][C-00000002] alertpipe.c: read() failed: Bad file descriptor

[2020-09-22 13:04:02] ERROR[3426] tcptls.c: Unable to connect SIP socket to 192.168.150.25:5080: Connection refused
[2020-09-22 13:04:02] ERROR[3427] tcptls.c: Unable to connect SIP socket to 192.168.150.26:5060: Connection refused
[2020-09-22 13:04:06] ERROR[3357][C-00000004] bridge_channel.c: We couldn’t write alert pipe for 0x7f99d002a4f0(SIP/trankfxs02-00000008)… something is VERY wrong
[2020-09-22 13:04:06] WARNING[3390][C-00000004] alertpipe.c: read() failed: Bad file descriptor
[2020-09-22 13:04:06] WARNING[3390][C-00000004] bridge_channel.c: Weird. No frame from bridge for SIP/trankfxs02-00000008 to process?
[2020-09-22 13:04:06] WARNING[3390][C-00000004] alertpipe.c: read() failed: Bad file descriptor
[2020-09-22 13:04:06] WARNING[3390][C-00000004] bridge_channel.c: Weird. No frame from bridge for SIP/trankfxs02-00000008 to process?
[2020-09-22 13:04:06] WARNING[3390][C-00000004] alertpipe.c: read() failed: Bad file descriptor
[2020-09-22 13:04:06] WARNING[3390][C-00000004] bridge_channel.c: Weird. No frame from bridge for SIP/trankfxs02-00000008 to process?
[2020-09-22 13:04:06] WARNING[3390][C-00000004] alertpipe.c: read() failed: Bad file descriptor
[2020-09-22 13:04:06] WARNING[3390][C-00000004] bridge_channel.c: Weird. No frame from bridge for SIP/trankfxs02-00000008 to process?
[2020-09-22 13:04:06] WARNING[3390][C-00000004] alertpipe.c: read() failed: Bad file descriptor
[2020-09-22 13:04:06] WARNING[3390][C-00000004] bridge_channel.c: Weird. No frame from bridge for SIP/trankfxs02-00000008 to process?

2

This could be a problem with using TCP in general. Since TCP uses connection based resources, you could be running out of file descriptors (for example) or some other stream-based resource. How many phones are you connecting to the system?

3

more than 200 in total, but on tcp there were only 4

4

more than 200 in total, but on tcp there were only 4

cynjut, did I understand you correctly? the problem was in tcp, and now when I turned it off, I can be calm that it won’t happen again?

5

The problem could have been in TCP, because TCP doesn’t release file handle resources as quickly as UDP. If you have a bunch of TCP connections open, you can run out of file handles, which is what I interpreted the problem to be.

Now, I am not a magician or coiler (there’s a reference you might not get) but if you turned TCP off on a lot of these connections and the problem went away, it’s not unreasonable to assume that was the problem. More analysis is clearly warranted.

6

Thank you for your help.

7

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.