[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-03-02 07:07 CST
====================================================================== 
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). 
====================================================================== 

---------------------------------------------------------------------- 
 (0132513) luckman212 (reporter) - 2011-03-02 07:07
 https://issues.asterisk.org/view.php?id=18884#c132513 
---------------------------------------------------------------------- 
I'd also like to add that while this might not seem like a serious bug it's
a quite frustrating one because anyone using a gui for asterisk (e.g.
FreePBX), every time they save the config it causes several modules to be
reloaded, MOH is one of them.  So even if you are not making moh-related
changes (e.g. just adding an extension) you will kill your MOH. 

Is there any idea where to even begin hunting for this bug?  would the bug
likely be in musiconhold.c or is it more of a timing bug?  anyone have any
idea? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-02 07:07 luckman212     Note Added: 0132513                          
======================================================================