[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-12 22:51 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0134870) luckman212 (reporter) - 2011-05-12 22:51
 https://issues.asterisk.org/view.php?id=18884#c134870 
---------------------------------------------------------------------- 
Does anyone have a workaround for this yet?  I would like to help debug
this but I don't even know where to begin looking.  is the bug in
res_timing_dahdi or res_musiconhold ?  or somewhere else?? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-12 22:51 luckman212     Note Added: 0134870                          
======================================================================