[Asterisk-Users] Re: System call succeed, asterisk sees failure

[Bill Michaelson]

Then I infer that the asterisk process is improperly retrieving or interpreting the System process completion code.  That would be a serious bug that could break a lot of applications.  I wonder if it is specific to some installations or more widespread.

The validity of the code in app_system.c is unclear to me at first glance...

        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;
        } else {
                if (res && ast_exists_extension(chan, chan->context, chan->exte\
n, chan->priority + 101, chan->callerid))
                        chan->priority+=100;
                res = 0;
        }

My reading of man pages indicates that the status return by system(2) (refer to wait()) is more than just the value set by an exit() call or returned by a main() function, which seems to be restricted to the low-order byte.  I haven't studied it through, but I'm wondering if the hi-order bit can be set, thus causing (res < 0) in spite of successful process completion (returning 0).

Could this be the problem?

From: Eric Stanley <barnabas at knicknack.net>
To: asterisk-users at lists.digium.com
Subject: Re: [Asterisk-Users] System cmd usage
Date: Fri, 20 Feb 2004 12:22:12 -0600
Reply-To: asterisk-users at lists.digium.com

I saw the same thing.  I think I determined that it always failed at the same 
point in the macro, no matter what command was being executed.  I just put 
the whole cleanup process in a shell script and I execute the shell script 
from the macro.

Eric




>Message: 2
>Date: Fri, 20 Feb 2004 12:48:36 -0500
>From: Bill Michaelson <bill at cosi.com>
>To: asterisk-users at lists.digium.com
>Subject: [Asterisk-Users] System cmd usage
>Reply-To: asterisk-users at lists.digium.com
>
>
>--------------030605000007040102040002
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Using John Todd's example for recording, from his cleanup/conversion 
>macro...
>
>; Turn the two in/out .wav files into a single .wav file with both channels
>exten => s,3,System(/usr/local/bin/wmix 
>${MONITORDIR}/${CALLFILENAME}-in.wav ${\
>MONITORDIR}/${CALLFILENAME}-out.wav > ${MONITORDIR}/${CALLFILENAME})
>;
>; Remove the old .wav files - we don't need them anymore.
>exten => s,4,System(/bin/rm ${MONITORDIR}/${CALLFILENAME}-in.wav 
>${MONITORDIR}/\
>${CALLFILENAME}-out.wav)
>;
>; This part of the routine compresses the .wav files into a .gsm file for
>;  better storage (about 1/5 the size of a .wav file).  Use "untoast" to 
>restor\
>e
>;  to normal wav file format. (toast and untoast are fairly standard on 
>Linux s\
>ystems)
>;
>exten => s,5,System(/usr/bin/toast -F ${MONITORDIR}/${CALLFILENAME})
>
>The wmix runs successfully (it produces the mixed file), and running "by 
>hand" from the shell indicates that it returns 0 to the shell.  But the 
>* console log seems to think it failed...
>
>    -- Executing System("SIP/248379-fe6e", "/usr/local/bin/wmix 
>/var/spool/asterisk/monitor/20040220-121235-111-916095326873-in.wav 
>/var/spool/asterisk/monitor/20040220-121235-111-916095326873-out.wav > 
>/var/spool/asterisk/monitor/20040220-121235-111-916095326873") in new stack
>Feb 20 12:12:56 WARNING[1209214528]: app_system.c:57 system_exec: Unable 
>to execute '/usr/local/bin/wmix 
>/var/spool/asterisk/monitor/20040220-121235-111-916095326873-in.wav 
>/var/spool/asterisk/monitor/20040220-121235-111-916095326873-out.wav > 
>/var/spool/asterisk/monitor/20040220-121235-111-916095326873'
>  == Spawn extension (macro-record-cleanup, s, 3) exited non-zero on 
>'SIP/248379-fe6e' in macro 'record-cleanup'
>  == Spawn extension (intern-post, s, 1) exited non-zero on 
>'SIP/248379-fe6e'
>
>Any ideas why?
>
>  
>