[asterisk-bugs] [JIRA] (ASTERISK-26019) Deadlock after 'core reload'

Andrew Nagy (JIRA) noreply at issues.asterisk.org
Thu May 12 19:44:56 CDT 2016


    [ https://issues.asterisk.org/jira/browse/ASTERISK-26019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=230600#comment-230600 ] 

Andrew Nagy edited comment on ASTERISK-26019 at 5/12/16 7:44 PM:
-----------------------------------------------------------------

This is because of ASTERISK-25996. Since I can't get AMI reload to generate the hints dynamically we were running an AMI reload then immediately after a dialplan reload. However there is an daemon also running in the background that detects reloads() and then tries to get the state of dyanmic hints through extensonState, because it's blocked by ASTERISK-25996 it has to use AMI "command dialplan" to force Asterisk to generate the hints.

This because sort of a snowball for Asterisk and eventually it just gives up on life. For now we've just taken out the dialplan reload. We've turned AMI reload into the CLI: asterisk -rx 'core reload' and it's solved all of our problems. Temporarily of course. I hope that soon/someday ASTERISK-25996 will be fixed :-) 

With regards to this ticket it can probably be closed in favor of ASTERISK-25996, though strangely Asterisk 11 never locked up (and it was getting the same "hits" as 13)


was (Author: tm1000):
This is because of ASTERISK-25996. Since I can't get AMI reload to generate the hints dynamically we were running an AMI reload then immediately after a dialplan reload. However there is an daemon also running in the background that detects reloads() and then tries to get the state of dyanmic hints through extensonState, because it's blocked by ASTERISK-25996 it has to use AMI "command dialplan" to force Asterisk to generate the hints.

This because sort of a snowball for Asterisk and eventually it just gives up on life. For now we've just taken out the dialplan reload. We've turned AMI reload into the CLI: asterisk -rx 'core reload' and it's solved all of our problems. Temporarily of course. I hope that soon/someday ASTERISK-25996 will be fixed :-) 

With regards to this ticket it can probably be closed in favor of ASTERISK-25996

> Deadlock after 'core reload'
> ----------------------------
>
>                 Key: ASTERISK-26019
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26019
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.8.0, 13.8.1, 13.8.2, 13.9.0
>            Reporter: Andrew Nagy
>         Attachments: backtrace-threads-lgaetzdev2-2016-05-12.txt
>
>
> This is a sporadic issue. Which makes it all the more fun.
> Occasionally while running "core reload" Asterisk will just up and stop all transactions. Extensions will unregister and calls will be dropped.
> When trying to run "core reload" again sometimes Asterisk will say "previous reload not finished" but if you try to run "core reload" again after that it just wont say anything.
> The CLI is still active at this point and there's been much debate about how to track down the bug.
> It's only an issue in Asterisk 13. I have attached GDB logs to this ticket for further analysis
> {code}
> lgaetzdev2*CLI> core reload
>     -- The previous reload command didn't finish yet
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list