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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Asterisk-Users] System cmd usage
Date: Fri, 20 Feb 2004 12:22:12 -0600
Reply-To: [EMAIL PROTECTED]

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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Asterisk-Users] System cmd usage
Reply-To: [EMAIL PROTECTED]


--------------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?





_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to