Bill Michaelson
2004-Feb-20 13:50 UTC
[Asterisk-Users] Re: System call succeed, asterisk sees failure
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@knicknack.net> To: asterisk-users@lists.digium.com Subject: Re: [Asterisk-Users] System cmd usage Date: Fri, 20 Feb 2004 12:22:12 -0600 Reply-To: asterisk-users@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@cosi.com> >To: asterisk-users@lists.digium.com >Subject: [Asterisk-Users] System cmd usage >Reply-To: asterisk-users@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? > > >