fax-process.pl not executing under 1.6.2.2

I keep getting a failure in the processing of fax-process.pl in the log. The log says:
WARNING[7926] app_system.c: Unable to execute
I'm sure it is something simple keeping this from working. Any suggestions? I'm running 2.7 beta 1.3 but I don't think this has anything to do with the command freepbx is generating.
rob
__________________



Additional info
I meant to put in here that I can run the command find as the asterisk user.
Clarification
I did some more research into this issue and it appears to me that the ast_safe_system function in app_system.c must be returning a -1. I'm going to post this issue over at the digium forums since it doesn't appear to have anything to do with FreePBX. I've seen other bugs reported in 1.6.2 related to similar issues. Just an FYI in case anyone else runs into the issue.
Symptoms:
- fax-process.pl returns "WARNING[7926] app_system.c: Unable to execute" in the asterisk log
- email of faxes does not occur
- command runs fine at the asterisk command prompt using ! in front of it meaning that the forking appears to work correctly.
do all System() commands in
do all System() commands in Asterisk 1.6.2 fail, or is it just this one?
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
No, not all
I inserted a basic system(ls -l /tmp) command and it ran fine. The command was NOT quoted in the dialplan.
[Feb 16 10:56:24] VERBOSE[26287] pbx.c: -- Executing [mynum@from-trunk:2] ^[[1;36mSystem^[[0m("^[[1;35mSIP/DefaultOut-00000048^[[0m", "^[[1;35mls -l /tmp^[[0m") in new stack
When I did quote the command it did not run which is what I think the issue is since the command using fax-process.pl is quoted with single quotes. It is probably another 1.6.2 syntax issue? Why would that change?
I'm going to test a fax using the unquoted system command to see if that works. I'll post back on the results. If it does work I'll open a ticket for it.
Crazy syntax
So when I removed the quotes the command worked properly. I did open a ticket but I'm not sure that removing the quotes is correct. I think this tracks back to a bug in ast_safe_system where the line below was added to app_system.c. It encodes the passed string so apparently the quotes are not required?
ast_str_get_encoded_str(&buf, 0, (char *) data);
can you check this out with
Skip what I asked (post erased) checking with devs, per my comment in the ticket, I think this may be a bug on our part and in any event works fine with no quotes in 1.4.x so ... (don't know about 1.2)
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
OK, got it
I was just creating the issue in asterisk tracker but will leave it alone per your request.
ip-rob, give that it works
ip-rob,
give that it works on 1.4 but not on 1.6, it may be worth pursuing with them anyhow in case it really is a bug. There may be dialplan out there that worked and is now broken. They may claim it was always a bug to do that or maybe not. For our case, I've chosen to remove the quotes and I think it is fine but as a general Asterisk issue, from what you have uncovered, it is worth at least bringing up with them.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
Reported...will see what happens
ID 0016842. Not sure if anything will happen.
Acknowledged in asterisk issue tracker
The bug has been acknowledged in asterisk so hopefully this will be fixed. In the meantime not quoting works.
I have the same issue. I am
I have the same issue. I am running Asterisk 1.6.2.3 and went ahead and got Fax For Asterisk (single user free license) from Digium. The system will receive a fax just fine and store it in the folder as a TIF file but the file never gets emailed out of that directory.
the quotes around the
the quotes around the system() call were removed. Is it still failing? If so, has there been any attempt at manipulating the format of the System() call to see if there is something we could produce that would work around the issue?
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
I haven't experimented too much
I know the quotes were an issue but there is clearly some other problem. I think it is something else in 1.6.2.2 (and apparently 1.6.2.3). I was going to try updating to 1.6.2.4 and see if that fixed it.
I can run the command at the asterisk prompt (prefixed by !) and the thing runs fine. The system call code in * seems to be problematic and I suspect it is in the fork process. For example, I can put a system call such as system(ls -l /tmp > /usr/src/temp.txt) and nothing happens with that either. There is no error in the asterisk log but no execution is happening at all.
I'll update to 1.6.2.4 and test...if the problem persists then I'll open another issue at digium.
to the person who solved the
to the person who solved the issue:
i have the same problem with asterisk 1.6.2.4
could you tell me which file i should edit and at which point to make it work?
thanks
Reported issue in asterisk issue tracker
ID 0016905 since the system() function appears to not work at all in 1.6.2.4.
Rob
Not asterisk - must be dialplan
I closed the ticket at asterisk because I was able to get the command to execute in asterisk. What I did was take the command that failed from the full log, created a new step in a dialplan to execute the command, and it did it fine.
This meant there must be something else wrong with the dialplan. I went through the generated line again and I believe there is an extra ) at the end of the line.
I'll open a ticket. I should have caught that when I look at this earlier.
can u give me the URL of
can u give me the URL of this ticket?
where i can follow the developments and news for this problem?
thanks a lot
Not a FreePBX issue
I posted a bug and after looking through it extensively it appears the dialplan from FreePBX is correct. The problem now looks like it is in the ExecIf statement of 1.6.2. I reopened a ticket with Asterisk which can be followed on Asterisk issue tracker. I'm going to run a few more tests to verify the issue and post more information to that ticket.
It isn't asterisk...I give, it won't work
OK, I did something very simple. I replaced the fax-process.pl line generated from the dialplan and replaced it with a simple script. That script executes.
fax-process.pl is not working in 1.6.2. I don't know why and give up. It has taken way too much of my time already.
it's not working? or it's
it's not working?
or it's not working when called form an ExecIf?
If just the latter, as mentioned in the ticket, we can change how we call it if need be if the issue is a general issue and we resolve it down to not working when called by ExecIf, until we get to root cause of why in that scenario.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
Isn't it too big of a time sink!
The ExecIf is working. I created simple scripts (below). When I call the script with the ExecIf in lieu of the fax-process.pl generated statement, it all works fine. But for some reason the ExecIf statement with fax-process.pl is not working.
So this points back to something in the generated statement that 1.6.2 doesn't like. Philippe, you've spent a lot of time on this already. I'm not sure you want to spend any more time on it...I know not excited about it!
Just as an FYI, here was the dialplan I created which worked.
exten => 9999,n,Set(FAX_RX_EMAIL="test@test.com")
exten => 9999,n(process),System(/usr/src/temp.sh)
exten => 9999,n(process),ExecIf($["${FAX_RX_EMAIL}" != ""]?system(/usr/src/temp2.sh)
temp.sh is
#!/bin/bash
ls -l /tmp > /tmp/temp.txt
temp2.sh is
#!/bin/bash
ls -l /tmp > /tmp/temp2.txt
When this dialplan executes both temp.txt and temp2.txt exist in /tmp. This indicates the ExecIf is working ok. I did make sure I purged /tmp before calling the extension.
ip-rob, but my question is
ip-rob,
but my question is does the faxprocess.pl work when called just from a a System call?
In other words, if we change the dialplan to this, would it work:
exten => h,n,GotoIf($["${FAX_RX_EMAIL}" != ""]?noemail) exten => h,n,System(fax-process.pl command here) exten => h(noemail),MacroExit()or something like that...
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
Yes, that would work
I've been able to get fax-process.pl to work without the ExecIf. So that should work.
ip-rob could you please tell
ip-rob could you please tell which files and how exactly to modify to make it work?
thanks a lot
Fix isn't available
kartaka
I haven't found a way to make the generated dialplan work. I have been able to successfully get fax-process.pl to work by removing the ExecIf statement and calling the script as system() in a test setup only.
For those of you who this is
For those of you who this is failing...
can you try the following patch:
functions.inc.php in fax module:
Index: functions.inc.php =================================================================== --- functions.inc.php (revision 9055) +++ functions.inc.php (working copy) @@ -265,7 +265,8 @@ } $exten = 'h'; $ext->add($context, $exten, '', new ext_gotoif('$["${FAXSTATUS:0:6}" = "FAILED"]', 'failed')); - $ext->add($context, $exten, 'process', new ext_execif('$["${FAX_RX_EMAIL}" != ""]','system','${ASTVARLIBDIR}/bin/fax-process.pl --to ${FAX_RX_EMAIL} --from "'.$sender_address['0'].'" --dest "${FROM_DID}" --subject "New fax from ${URIENCODE(${CALLERID(name)})} ${URIENCODE(<${CALLERID(number)}>)}" --attachment fax_${URIENCODE(${CALLERID(number)})}.pdf --type application/pdf --file ${ASTSPOOLDIR}/fax/${UNIQUEID}.tif')); + $ext->add($context, $exten, 'process', new ext_gotoif('$["${FAX_RX_EMAIL}" = ""]','end')); + $ext->add($context, $exten, '', new ext_system('${ASTVARLIBDIR}/bin/fax-process.pl --to ${FAX_RX_EMAIL} --from "'.$sender_address['0'].'" --dest "${FROM_DID}" --subject "New fax from ${URIENCODE(${CALLERID(name)})} ${URIENCODE(<${CALLERID(number)}>)}" --attachment fax_${URIENCODE(${CALLERID(number)})}.pdf --type application/pdf --file ${ASTSPOOLDIR}/fax/${UNIQUEID}.tif')); $ext->add($context, $exten, 'end', new ext_macro('hangupcall')); $ext->add($context, $exten, 'failed', new ext_noop('FAX ${FAXSTATUS} for: ${FAX_RX_EMAIL} , From: ${CALLERID(all)}'),'process',101);Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
patch applied, will test later tonight
My fax machine is at home so I'll test this evening. I did apply the patch and the generated dialplan looks good. Will post my results here.
it works!
I can't explain why the ExecIf fails in 1.6.2 but the revised GotoIf worked perfectly.
Thanks!
ok well go and hammer on the
ok well go and hammer on the Asterisk team to figure out what is up. In the mean time, if you could, open a new bug about the failure mode on 1.6.2 mentioning it is an * issue, and I'll get this checked in against that bug and we'll just compensate for the fact that * has issues for now on some versions.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
Ticket 4096 opened
I put your patch and opened ticket 4096. I'll reopen my ticket again at digium. I'm going to put in the exact generated dialplan and tell them it is broken. They've been a pain to get to accept the ticket before but I'll do what I can.
the patch did not work for
the patch did not work for me.
maybe i didnt apply it well?
anyway the asterisk log file full shows', expecting $end; Input:
cd /var/www/freepbx/admin/modules
WARNING[3680] ast_expr2.fl: ast_yyerror(): syntax error: syntax error, unexpected '
""xxxx@xxxxx.com"" = ""
^
I hope you ll make an update to fax module, if your patch works for most people
kartaka, can you paste a few
kartaka,
can you paste a few lines before and after that warning so we can see where it came from please.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
solved resolved with your
solved
resolved with your latest fax module update
thanks
kartaka, it would still be
kartaka,
it would still be very helpful for you to provide us with more lines of your warning above (which should still be available in the log file).
The new module was a 'workaround' to the issue suspected to be an Asterisk issue but true resolution has not been determined.
Your message above is a real issue and we would like to know where it came from so we can determine what is providing bad syntax which may also point to root cause of the other issue.
I'm glad that your fax is working but please go dig up that information requested and provide it to us so we can see what that was about and determine if it was relate or another un-reported bug.
Thanks.
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here
actually i had applied tha
actually i had applied tha patch manually.
maybe i did not apply it well.
it was a copy paste.
After updating the fax module, i have no issues, so i cannot reproduce it
thanks
One issue resolved by asterisk
The quote issue has been resolved by asterisk. The ticket, 0016842, has a patch attached that resolves the quoting problem. I tested the patch and it worked fine. I'm getting ready to test the patch for the ExecIf to see if that resolves the problem.
Rob
Other fix works
Their fix for the ExecIf problem also worked. Ticket 0016905 fixes the issue related to ExecIf's in 1.6.2.2.
thanks for staying on top of
thanks for staying on top of this. We'll probably leave the code as is in FreePBX for quite some time as it will take a long time for that bug to works its way out of installed Asterisk systems and the current dialplan works just fine, one extra instruction isn't going to hurt anything :)
Philippe Lindheimer - FreePBX Project Leader
FreePBX Training Opportunities - Click Here
Get Official Paid Support - Click Here