[Home]

Summary:ASTERISK-01071: System call in dialplan erroneously reports failure
Reporter:Bill Michaelson (billmichaelson)Labels:
Date Opened:2004-02-21 11:32:02.000-0600Date Closed:2008-01-15 14:44:52.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:A system call to invoke a file conversion process (in my case, /usr/local/bin/wmix) functions properly, producing the appropriate output.  But the invoking module (app_system.c) gets a -1 return from the system() call with errno set to 10.  This causes improper completion of the remaining steps in my dialplan.  See extensions.conf fragment in add'l info.  In that example, the context is a macro which aborts after step 3 with a message indicating that the system call failed, in spite of the fact that the output file is actually created with no apparent problems.

Email me at bill@cosi.com for more info as required.


****** ADDITIONAL INFORMATION ******

exten => s,3,System(/usr/local/bin/wmix ${MONITORDIR}/${CALLFILENAME}-in.wav ${MONITORDIR}/${CALLFILENAME}-out.wav > ${MONITORDIR}/${CALLFILENAME})


exten => s,4,System(/bin/rm ${MONITORDIR}/${CALLFILENAME}-in.wav ${MONITORDIR}/${CALLFILENAME}-out.wav)

exten => s,5,System(/usr/bin/toast -F ${MONITORDIR}/${CALLFILENAME})

exten => s,6,NoOp


Comments:By: Bill Michaelson (billmichaelson) 2004-02-21 11:38:46.000-0600

Further to above - this problem occurs on stock Redhat 9.  I've modified app_system.c to get more precise info (see below).  That's how I know the system() call actually returns -1...

       res = system((char *)data);
       /*
       if (res < 0) {
               ast_log(LOG_WARNING, "Unable to execute '%s'\n", (char *)data);
               res = -1;
       } else if (res == 127) {
               ast_log(LOG_WARNING, "Unable to execute '%s'\n", (char *)data);
               res = -1;
       */
       if (res == -1) {
               ast_log(LOG_WARNING, "Fork failed for '%s'; errno %d\n", (char *)data, errno);
               res = -1;
       } else if (WEXITSTATUS(res) != 0) {
               ast_log(LOG_WARNING, "Error completion for '%s'\n", (char *)data);
               res = -1;
By: James Golovich (jamesgolovich) 2004-02-21 13:36:30.000-0600

Have you checked the wmix code to see what value it is exiting with?  That is generally where this type of problem comes from
By: Brian West (bkw918) 2004-02-21 20:30:18.000-0600

Accually this isn't needed anymore if you have soxmix on your system you can have monitor called with the "m" flag and it will mux the files when the call completes in the background.
By: Bill Michaelson (billmichaelson) 2004-02-24 10:25:09.000-0600

I had independently run wmix and echoed $? from the shell.  It returns 0.  I might surmise that the circumstances are different in the * process environment, in spite of the fact that wmix produces valid output, and by that account, succeeds.

However, as indicated above, I modified the * code in app_system.c so that I can state with confidence that the first of the tested failure conditions (res == -1) is the one encountered.  I believe that this is improper, regardless of the completion code that would be returned from wmix in any case.

bkw <- thanks for the tip.  That would appear to consolidate operations in such a way that allows me to accomplish the task in a single step.

But of course, the essential problem remains, and is a potential show-stopper in other hypothetical situations.
By: Mark Spencer (markster) 2004-02-27 02:10:49.000-0600

Well I've fixed it to ignore the ECHILD, but that also means we don't get a good return code in those cases.  This should solve your problem at least.  If not, reopen.
By: Digium Subversion (svnbot) 2008-01-15 14:44:52.000-0600

Repository: asterisk
Revision: 2265

U   branches/v1-0_stable/apps/app_system.c

------------------------------------------------------------------------
r2265 | markster | 2008-01-15 14:44:52 -0600 (Tue, 15 Jan 2008) | 2 lines

Ignore ECHILD in app_system() (bug ASTERISK-1071)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=2265