[asterisk-bugs] [Asterisk 0012709]: reload stops all action on CLI

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12709 
====================================================================== 
Reported By:                Yourname
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12709
Category:                   Applications/app_cdr
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-22-2008 23:02 CDT
Last Modified:              05-30-2008 12:27 CDT
====================================================================== 
Summary:                    reload stops all action on CLI
Description: 
Mailing list:
http://lists.digium.com/pipermail/asterisk-users/2008-May/212281.html

After doing a few changes in queues.conf, I tried reload app_queue.so,
nothing happened on CLI. So I tried reload, and nothing happened. Something
similar happened to be long ago, and from then I knew something bad is
going to happen like no calls can come in or go out, agents login or out,
etc..

These commands go by and NOTHING happens on the CLI. Even stop now didn't
work. So I ctrl+c out of the CLI and then 'service asterisk stop'. Seems
like it did, but on the shell it kept doing the "Asterisk died with
code..." 

So I attempted to stop asterisk again, and also tried killall asterisk.
Finally it all worked, and then I safe_asterisk'd. Been scared to reload
ever since.
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 05-30-08 12:27  
---------------------------------------------------------------------- 
Once again, I think we're having some communications failures here. In your
original bug report, you made no mention of any crashes occurring. The last
two core dumps you provided were taken from a system with DO_CRASH enabled
in menuselect, which will cause crashes to occur when certain error
conditions arise. Those crashes most likely have nothing at all to do with
the original deadlock you reported. I'm not sure whose advice you were
following by enabling DO_CRASH, but in my view it doesn't help at all in
resolving this issue and should never be enabled on a production box. I
apologize to you for whoever told you to enable that.

So let's get back to square one here. You reported that when attempting to
reload app_queue, the CLI was unresponsive and calls could not be
completed. When this happens, this is when I need to see core show locks
output, because that is when the failure has occurred and that's when the
system is in a state where the output of that command is useful. If the CLI
is not responsive to commands, you can attempt to connect to asterisk from
another console with asterisk -r. This sometimes will work in getting CLI
responsiveness again.

If there have also been crashes occurring (not counting the ones that
happened when DO_CRASH was enabled) then backtraces from those crashes will
be helpful too. From what I see, every backtrace provided so far has been
from a crash point caused by DO_CRASH.

With regards to the deadlocks reported on the CLI, you shouldn't worry
about those unless there is a noticeable problem (i.e. calls can't
complete, CPU % spikes, etc.). The deadlock detection works in Asterisk by
seeing if it's taking an excessive amount of time to acquire a lock. In
some cases, it may really just need that long. In the case of chan_agent,
however, you'll see deadlock messages all over the CLI when agents are on
the phone because there's actually a deadlock built into the channel driver
on purpose. This deadlock clears itself when an agent hangs up. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-30-08 12:27  putnopvut      Note Added: 0087563                          
======================================================================