[asterisk-bugs] [Asterisk 0018884]: when using mpg123 as a streaming MOH source, issuing 'moh reload' from CLI causes stream to die

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18884 
====================================================================== 
Reported By:                luckman212
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18884
Category:                   Resources/res_musiconhold
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.8.2.3 
JIRA:                       SWP-3201 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-02-24 13:48 CST
Last Modified:              2011-05-23 18:56 CDT
====================================================================== 
Summary:                    when using mpg123 as a streaming MOH source, issuing
'moh reload' from CLI causes stream to die
Description: 
Title says it all, I have a single stream set up as a MOH source, with the
following code (server ip removed)

[stream]
mode=custom
application=/usr/bin/mpg123 -q -s -m -r 8000 -f 2048 -b 0
http://my.streaming.server/stream_mp3


Everything works fine upon the initial load.  But after issuing a 'moh
reload' the stream goes dead.  I checked to make sure MPG123 is still
running (ps aux| grep mpg123) and yes it is.  I turned on verbose logging
via logger.conf and noted the following while issuing 'moh reload':

[2011-02-24 14:45:15] VERBOSE[24722] config.c:   == Parsing
'/etc/asterisk/musiconhold.conf': [2011-02-24 14:45:15] VERBOSE[24722]
config.c:   == Found
[2011-02-24 14:45:15] VERBOSE[24722] config.c:   == Parsing
'/etc/asterisk/musiconhold_custom.conf': [2011-02-24 14:45:15]
VERBOSE[24722] config.c:   == Found
[2011-02-24 14:45:15] VERBOSE[24722] config.c:   == Parsing
'/etc/asterisk/musiconhold_additional.conf': [2011-02-24 14:45:15]
VERBOSE[24722] config.c:   == Found
[2011-02-24 14:45:15] DEBUG[24722] res_musiconhold.c: killing 24322!
[2011-02-24 14:45:15] DEBUG[24722] res_musiconhold.c: mpg123 pid 24322 and
child died after 56752 bytes read
[2011-02-24 14:45:48] VERBOSE[26009] config.c:   == Parsing
'/etc/asterisk/musiconhold.conf': [2011-02-24 14:45:48] VERBOSE[26009]
config.c:   == Found
[2011-02-24 14:45:48] VERBOSE[26009] config.c:   == Parsing
'/etc/asterisk/musiconhold_custom.conf': [2011-02-24 14:45:48]
VERBOSE[26009] config.c:   == Found
[2011-02-24 14:45:48] VERBOSE[26009] config.c:   == Parsing
'/etc/asterisk/musiconhold_additional.conf': [2011-02-24 14:45:48]
VERBOSE[26009] config.c:   == Found
[2011-02-24 14:45:48] DEBUG[26009] res_musiconhold.c: killing 25173!
[2011-02-24 14:45:48] DEBUG[26009] res_musiconhold.c: mpg123 pid 25173 and
child died after 60408 bytes read


I checked these PIDs against the 'ps aux' output and confirmed that they
are aligned & correct.  The fact that mpg123 says "60408 bytes read" even
though calling the moh extension leads to silence leads me to believe that
the pipe somehow got messed up but MPG123 was still streaming data (I
confirmed this by watching traffic on my router with tcpdump). 
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0018800 Res_musiconhold Kills Mpg123 Upon Initi...
====================================================================== 

---------------------------------------------------------------------- 
 (0135316) luckman212 (reporter) - 2011-05-23 18:56
 https://issues.asterisk.org/view.php?id=18884#c135316 
---------------------------------------------------------------------- 
Wow this would be truly fantastic.  This issue has been plaguing me for
almost a year!  I am so curious what the issue is, my PBX is not able to
use the res_timer_timerfd so I am limited to pthread & dahdi timers.  It
definitely does seem like a dahdi issue (disabling dahdi works around it
but causes extreme instability on my system). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-23 18:56 luckman212     Note Added: 0135316                          
======================================================================