| Summary: | ASTERISK-28395: Asterisk occasionally fails to hangup channels | ||||||
| Reporter: | Stefan Repke (stefffan@gmx.de) | Labels: | |||||
| Date Opened: | 2019-04-25 08:13:31 | Date Closed: | 2019-07-01 08:33:08 | ||||
| Priority: | Major | Regression? | |||||
| Status: | Closed/Complete | Components: | Channels/chan_iax2 Channels/chan_sip/General PBX/General | ||||
| Versions: | 13.8.2 | Frequency of Occurrence | Occasional | ||||
| Related Issues: |
| ||||||
| Environment: | Debian Linux | Attachments: | ( 0) case1.txt ( 1) case2.txt ( 2) case3.txt | ||||
| Description: | Our Asterisk servers occasionally fail to hangup channels (IAX2 or SIP).
We are running version: 13.8.2. The symptoms are as follows: * We observe a HangupRequest event via AMI but the Hangup event does not occur. * One Asterisk thread starts consuming 100% CPU, i.e. burning one core. * Strange warning messages occur in CLI and log repeatedly every few seconds: ** IAX case: {noformat} WARNING[15982] chan_iax2.c: Max retries exceeded to host 10.101.1.5 on IAX2/125-5832 (type = 6, subclass = 11, ts=119996, seqno=24) {noformat} ** SIP case: {noformat} WARNING[21518]: chan_sip.c:4333 __sip_autodestruct: Autodestruct on dialog 'e8954fa42ffee2d1ace1ac4c6323d990@10.249.4.97' with owner SIP/999222-0000149c in place (Method: BYE). Rescheduling destruction for 10000 ms {noformat} * The channel stays alive (i.e. still visible via CLI, AMI status, ARI, etc). * The channel cannot be hungup (via CLI, AMI, etc). * The only fix is to restart Asterisk. Up to now, we were facing this problem three times: # IAX2 channel, thread {{bridge_channel_depart_thread}} # SIP channel, thread {{pbx_thread}} # SIP channel, thread {{pbx_thread}}, with thread debugging enabled (includes {{strace}} output). I've attached the debug info for each of the above cases. Maybe this bug is related to: * ASTERISK-25911 * ASTERISK-27538 --- I can imagine that you need more detailed information to track down this bug. If so, please let me know how I can provide it and I will try to reproduce this problem. | ||||||
| Comments: | By: Asterisk Team (asteriskteam) 2019-04-25 08:13:32.343-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Kevin Harwell (kharwell) 2019-04-25 18:25:08.977-0500 [~stefffan@gmx.de] Let me start by saying thank you for the level of effort put into your report, and into the collection of the data! As a heads up I'll mention that these channel drivers don't see a lot of updates, and bug fixes these days. For instance, _chan_sip_ is officially deprecated, and is mostly community supported by developers outside Sangoma. So "fix times" will be reflective of that. That being said there are at least two things to try that could be helpful: 1. You're on 13.8.2. This of course is an older version of Asterisk. Please upgrade to the latest release (currently 13.26.0 and 16.3.0). _chan_iax_ doesn't appear to have as many updates since then, but there are a few in _chan_sip_, so maybe something got fixed. 2. A backtrace of Asterisk when a channel gets stuck could potentially help. Running an older version you'll have to do this more manually [1]. However, if you are able to upgrade then you can use the _ast_coredumper_ script [2] to obtain a "running" core dump & subsequent backtrace of Asterisk. *Note*, using _ast_coredumper's_ '--running' option will interrupt call processing. [1] https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=5243139 [2] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Kevin Harwell (kharwell) 2019-04-25 18:28:44.611-0500 Oh also it's entirely possible (and more than likely) these are two separate issues. You've already found two potential issues that may be related or even the same issues. Both sound like they could be, so for sure worth monitoring their progress. By: Asterisk Team (asteriskteam) 2019-05-10 12:00:01.938-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Stefan Repke (stefffan@gmx.de) 2019-07-01 08:32:42.849-0500 We were not able to reproduce the problem with current versions of Asterisk 13 and 16. Seems to be solved ... By: Asterisk Team (asteriskteam) 2019-07-01 08:32:43.326-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. | ||||||