[Home]

Summary:ASTERISK-24422: Monitor still alive after channel is hanged up
Reporter:Dmitry Pischenko (d.pischenko)Labels:
Date Opened:2014-10-15 03:32:44Date Closed:2014-12-08 11:37:09.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/General
Versions:11.11.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) monitor-leaks.patch
Description:Monitor still alive after channel is hanged up.

Dialplan example:
{noformat}
exten => _4XXX,n,Monitor(gsm,${UNIQUEID},b)
exten => _4XXX,n,Dial(SIP/KMPX/1${EXTEN:1})
exten => _4XXX,n,Hangup
{noformat}

After hanging up ast_monitor_stop() called one time with one of channels. If monitor started on other channel then ast_monitor_stop() do not call with other channel. After each call asterisk holds output files. And after some time asterisk cannot create any descriptors and I need restart asterisk.

lsof when all calls is over:

{noformat}
asterisk   1009       root   31w      REG        8,2   491520    2627254 /var/spool/asterisk/monitor/softpbx11-1413208359.0-in.gsm
asterisk   1009       root   32u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   33w      REG        8,2    98304    2627258 /var/spool/asterisk/monitor/softpbx11-1413208735.11-in.gsm
asterisk   1009       root   34u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   35w      REG        8,2   491520    2627255 /var/spool/asterisk/monitor/softpbx11-1413208359.0-out.gsm
asterisk   1009       root   36u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   37u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   38w      REG        8,2       99    2627256 /var/spool/asterisk/monitor/softpbx11-1413208463.3-in.gsm
asterisk   1009       root   39w      REG        8,2        0    2627257 /var/spool/asterisk/monitor/softpbx11-1413208463.3-out.gsm
asterisk   1009       root   40u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   41u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   42u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   43w      REG        8,2    98304    2627259 /var/spool/asterisk/monitor/softpbx11-1413208735.11-out.gsm
asterisk   1009       root   44w      REG        8,2    65536    2627260 /var/spool/asterisk/monitor/softpbx11-1413208826.14-in.gsm
asterisk   1009       root   45w      REG        8,2    65536    2627261 /var/spool/asterisk/monitor/softpbx11-1413208826.14-out.gsm
asterisk   1009       root   47u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   49u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   50w      REG        8,2   360448    2627262 /var/spool/asterisk/monitor/softpbx11-1413208932.16-in.gsm
asterisk   1009       root   51w      REG        8,2   360580    2627263 /var/spool/asterisk/monitor/softpbx11-1413208932.16-out.gsm
asterisk   1009       root   52u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   53w      REG        8,2   131072    2627266 /var/spool/asterisk/monitor/softpbx11-1413209382.22-in.gsm
asterisk   1009       root   54w      REG        8,2    65536    2627264 /var/spool/asterisk/monitor/softpbx11-1413209274.19-in.gsm
asterisk   1009       root   55w      REG        8,2    65536    2627265 /var/spool/asterisk/monitor/softpbx11-1413209274.19-out.gsm
asterisk   1009       root   58u      CHR    196,253      0t0       9995 /dev/dahdi/timer
asterisk   1009       root   59w      REG        8,2   131072    2627267 /var/spool/asterisk/monitor/softpbx11-1413209382.22-out.gsm
{noformat}

This affected in 11.11 but I see similar code in trunk. I do not check trunk but I guess that situation is present in trunk too.

I suggest patch in attached file. Patch to revision 425385
Comments:By: Matt Jordan (mjordan) 2014-10-28 09:03:49.062-0500

Unfortunately, that patch is not the correct way to resolve that problem. A soft hangup is not necessarily a hangup - a soft hangup may merely indicate that the channel must leave a bridge. As it is, that patch will make it so that on some nominal code paths, a monitor/MoH will be terminated on a valid channel that is still alive.

Since these calls are already made in the {{ast_channel_destructor}}, there should be no need to replicate them elsewhere. You most likely have a channel ref leak if these functions are not being called.

Please provide a DEBUG log illustrating the problem, as well as a ref debug log.

https://wiki.asterisk.org/wiki/display/AST/Reference+Count+Debugging

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: Rusty Newton (rnewton) 2014-11-13 17:08:43.510-0600

[~d.pischenko] we haven't heard back from you in a few weeks. Will you be able to provide the requested debug? Thanks!
By: Matt Jordan (mjordan) 2014-12-08 11:35:28.667-0600

I'm going to go out on a limb and say that this isn't the problem any way. In {{ast_channel_destructor}}:

{code}
/* Stop monitoring */
if (ast_channel_monitor(chan)) {
ast_channel_monitor(chan)->stop(chan, 0);
}
{code}

If a channel is destroyed and it has a Monitor on it, we will unilaterally stop the Monitor.

My guess is that [~d.pischenko] has a channel reference leak, as that would exhibit the behaviour he is seeing. However, without any information on how his system got into that state, there's no way we can reproduce or diagnose the problem.
By: Matt Jordan (mjordan) 2014-12-08 11:37:09.611-0600

Closing out as "Suspended".

If the reporter comes back, we'll need:
# Step by step instructions that reproduce the problem, including dialplan.
# DEBUG logs illustrating the issue
# Preferably, {{REF_DEBUG}} logs showing the channel leak.

Instructions for getting the logs can be found on the Asterisk wiki:
* https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
* https://wiki.asterisk.org/wiki/display/AST/Reference+Count+Debugging