[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-04 07:32 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). 
====================================================================== 

---------------------------------------------------------------------- 
 (0132637) luckman212 (reporter) - 2011-03-04 07:32
 https://issues.asterisk.org/view.php?id=18884#c132637 
---------------------------------------------------------------------- 
I noticed today that a new version of DAHDI has been released
(2.4.1+2.4.1)
http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/

Perhaps there are changes in there that might positively impact this bug? 
I haven't recompiled yet.  Plan to do so this weekend. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-04 07:32 luckman212     Note Added: 0132637                          
======================================================================