For some reason phpagi script randomly stop's in the middle. This only happens once every 20-50 calls. I was able to notice several such 'fails' realtime in asterisk CLI. No error's were displayed. Script sent several verbose messages until just stopped.
Script is used for billing, it has several while's and sql queries. max execution time set to 30seconds.
I didn't find any errors in the /var/log/messages or /var/log/asterisk/messages
Asterisk 1.6.2.24
PHP 5.1.6 (cli) (built: Jun 27 2012 12:21:13)
[context-x]
exten => 1,1,Dial(SIP/XXXXXX)
exten => h,1,AGI(script.php)
Any ideas why it could just stop for random calls?
Thanks.
UPDATE:
I've just noticed that when the problem occurs AGI returns 4:
-- <SIP/xxxxxx-00000185>AGI Script script.php completed, returning 4
What's wrong?
From what I'm hearing from your symptoms, it doesn't sound like it's specifically an Asterisk issue, but, could be an issue with your script. Here's a number of tips regarding how I would go about debugging an application without any knowledge of what's happening behind the scenes of the AGI script itself...
Firstly, AGI Script script.php completed, returning 4 means that your script is exiting without a clean exit status code. returning 0 is what you'd like to see. You can see the last exit status code at your bash prompt by running a script and then checking the status code with the $? variable. Like so:
[user#host ~]$ ./script.php
[user#host ~]$ echo $?
0
That's what Asterisk is telling you what happened to your script. Anything non-zero is "something's wrong here". Generally, you can customize these to your liking, so specifically 4, I'm not sure.
One thing you'll want to do is turn on agi debugging like so:
host*CLI> agi set debug on
Then run your script, and see if you can find that your php script is spitting out any errors.
Another recommendation that I would have is to make sure your php is logging to your syslog so that you can find errors in /var/log/messages. You can do this by setting in your /etc/php.ini this line:
error_log = syslog
Lastly, to try to replicate the error, I would suggest using a development box, and originate a bunch of calls for yourself, and build a script to create a bunch of "call files".
Here's a call file to get you started:
Channel: LOCAL/100#mycontext
MaxRetries: 2
RetryTime: 60
WaitTime: 30
Application: Wait
Data: 30
When you've created a file, move it to /var/spool/asterisk/outgoing (Moving is important, you want the pointer move, because asterisk may pick up the file too soon if you're writing to it in that directory first).
You can also originate a call on an extension from the CLI:
host*CLI> channel originate LOCAL/100#mycontext application Wait 5
You may also want to use other options in the call file, such as CallerID: John Doe <8005551212> in order to feed interesting data to your AGI application while you create tests to replicate the issue.
Related
I'm running a udev rule on my 3D printing server to automatically create easily identifyable symlinks to some attached microcontroller boards, which worked perfectly fine on ubuntu 20.04.
The rule triggers on the usb vendor and product ids and runs a python script via the PROGRAM directive. The script connects to the Microcontroller boards and reads it's init sequence to get the board's 'name'. It then outputs a string like "aaaaaaa b cccccc" and only the first block (containing the name) is used in the udev rule.
However, it seems like the whole PROGRAM directive is not executed at all anymore, since I updated my system to ubuntu 22.04.1.
My udev rule currently looks like this (While debugging. Regularly it just contained lines 1 and 3. I added #2 for testing purposes because the hook in line 1 works and that script is executed):
KERNELS=="ttyUSB*", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", ENV{ID_SERIAL_SHORT}!="AI046A0Q", ACTION=="add|remove", RUN="/bin/su me -c \"/opt/me/deviceReg.py -d %k -a %E{ACTION}\""
KERNELS=="ttyUSB*", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", ENV{ID_SERIAL_SHORT}!="AI046A0Q", ACTION=="add|remove", PROGRAM="/opt/me/serialUdev.py -s %s{serial} /dev/%k", SYMLINK+="%c{1}", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}!="AI046A0Q", PROGRAM="/opt/me/serialUdev.py -s %s{serial} /dev/%k", SYMLINK+="%c{1}", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9QXPRV7", SYMLINK+="tty_MainSwitch", GROUP="dialout", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9QOIMJ6", SYMLINK+="tty_Cooler", GROUP="dialout", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9PTMHGV", SYMLINK+="tty_CurrentTransformer", GROUP="dialout", OWNER="me", GOTO="script_end"
The python scripts write to some logfiles which clearly indicate that only lines 1 and 4, 5 or 6 are executed.
Is there anything in line 3 that isn't supported anymore in the latest udev version? As I said, line 3 worked perfectly before I updated the system.
The last 3 lines are my current workaround. They work fine but that's not what I want to achive with this whole naming system at all.
The python script in lines 2 & 3 runs perfectly fine, either if called as standard user or as root. It would also deliver valid output if the '-s ' input data is not matching the uc board, is missing or is random garbage.
Does anyone have an idea why the script omits any line with a PROGRAM statement?
Ok, I was able to solve the issue.
I set udev's log level to debug too see what's actually happening when the device is handled. The script actually IS invoked but immediately failed during importing needed modules: The pyserial module could not be found.
The module is installed though, but obviously in a way it could not be imported.
However, I checked the python script again and changed the first line from #!/usr/bin/env python3 to #!/usr/bin/python3 and now it works again.
So my problem actually wasn't related to udev at all, it was just my python script.
I'm trying to execute a command remotely through Robot Framework which is failing through Robot framework and giving me the wrong exit status of 13.
But if we run this manually exit status of TTman.sh is 112 which is actually pass(Not the standard return codes).
am I doing something wrong here?
You are not getting the remote code of the remote command, in fact the RC 13 you are getting from the run is most probably from the robotframework - on run completion its RC is the number of failed cases. I.e. 13 cases should have failed, when you observed this.
To get the return code of your command, a few changes in the case are needed; this is how the semi-last line should look like, with explanations below:
${rc}= Execute Command your_command_from_the_question &>/dev/null; echo $?
First, all the output of your command (stdout & stderr) is redirected to /dev/null - to not return it. Then the special var $? is printed - it holds the RC of the last executed command (and is available in most *sh variants, like bash).
Finally, that value is stored in the ${rc} robotframework variable, and you can do whatever checks you need on it, further in the case.
This approach has one drawback - as stderr is hidden, you will not be able to see any errors coming from running the command. But if it was not, then they would be interleaved with the RC, which would have required further processing of the {rc} var, to get the desired value. If you need it (the stderr output in case of failures), change accordingly.
P.S. don't add screenshots of a source in a question, it is much less usable than a text version.
I am attempting to get Phabricator running on Solaris over apache. The website is working, but all of the cli scripts are not. For example, phd.
The first problem, is that it is not passing arguments to the underling manage-daemons.php script that it invokes. Looking at the phd file, this does not surprise me:
$> cat phd
../scripts/daemon/manage_daemons.php
Now, given my default shell is bash, this isn't going to pass-through my arguments. To do this, I have modified the script:
#! /bin/bash
../scripts/daemon/manage_daemons.php $*
This will now pass-through the arguments, but it's now failing to find transative scripts it requires via relative path:
./phd start
Preparing to launch daemons.
NOTE: Logs will appear in '/var/tmp/phd/log/daemons.log'.
Launching daemon "PhabricatorRepositoryPullLocalDaemon".
[2014-05-09 19:29:59] EXCEPTION: (CommandException) Command failed with error #127!
COMMAND
exec ./phd-daemon 'PhabricatorRepositoryPullLocalDaemon' --daemonize --log='/var/tmp/phd/log/daemons.log' --phd='/var/tmp/phd/pid'
STDOUT
(empty)
STDERR
./phd-daemon: line 1: launch_daemon.php: not found
at [/XXX/XXX/libphutil/src/future/exec/ExecFuture.php:398]
#0 ExecFuture::resolvex() called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementWorkflow.php:167]
#1 PhabricatorDaemonManagementWorkflow::launchDaemon(PhabricatorRepositoryPullLocalDaemon, Array , false) called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementWorkflow.php:246]
#2 PhabricatorDaemonManagementWorkflow::executeStartCommand() called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementStartWorkflow.php:18]
#3 PhabricatorDaemonManagementStartWorkflow::execute(Object PhutilArgumentParser) called at [/XXX/XXX/libphutil/src/parser/argument/PhutilArgumentParser.php:396]
#4 PhutilArgumentParser::parseWorkflowsFull(Array of size 9 starting with: { 0 => Object PhabricatorDaemonManagementListWorkflow }) called at [/XXX/XXX/libphutil/src/parser/argument/PhutilArgumentParser.php:292]
#5 PhutilArgumentParser::parseWorkflows(Array of size 9 starting with: { 0 => Object PhabricatorDaemonManagementListWorkflow }) called at [/XXX/XXX/phabricator/scripts/daemon/manage_daemons.php:30]
Note I have obscured my paths with XXX as they give away sensitive information.
Now, obviously I shouldn't be modifying these scripts. This is an indication that some prerequisite is not set up properly.
It's clear to me that Phabricator is making some (bold) assumption about my setup. But I'm not quite sure what...?
These are supposed to be symlinks. For example, if you look at "phd" in the repository on GitHub, you can see that the file type is "symbolic link":
https://github.com/facebook/phabricator/blob/master/bin/phd
Something in your environment is incorrectly turning the symlinks into normal files. I'm not aware of any Git configuration which can cause this, although it's possible there is something. One situation where I've seen this happen is when a working copy was cloned, then copied using something like rsync without appropriate flags to preserve symlinks.
I'm really just looking to pick the community's brain for some leads in figuring out what is going on with the issue I'm having.
I'm writing a MR job with RHadoop (rmr2, v3.0.0) and things are great -- IO with HDFS, mapping, reducing. No problems. Life is great.
I'm trying to schedule the job with Apache Oozie, and am running into some issues:
Error in mr(map = map, reduce = reduce, combine = combine, vectorized.reduce, :
hadoop streaming failed with error code 1
I've read the rmr2 debugging guide, but nothing is really getting to the stderr because the job fails before anything even gets scheduled.
In my head, everything points to a difference in environments. However, Oozie is running the job as the same user that I'm able to run everything with via cli, and all of the R environment variables (fetched with Sys.getenv()) are the same, excepting there's some additional class path stuff set with Oozie.
I can post more of the OS or Hadoop versions and config details, but sleuthing some version-specific bugs seems like a bit of a red herring as everything runs fine at the command line.
Anybody have any thoughts what might be some helpful next steps in hunting this beast down?
UPDATE:
I overwrote the system function in the base package to log the user, the host name of the node, and the command being executed before the internal call to system. So before any system call is actually executed, I get something like the following in the stderr:
user#host.name
/usr/bin/hadoop jar /usr/lib/hadoop-mapreduce/hadoop-streaming-2.2.0.2.0.6.0-102.jar ...
When ran with Oozie, the command printed in the stderr fails with an exit status of 1. When I run the command on user#host.name, it runs successfully. So essentially the EXACT same command with the SAME user on the SAME node fails with Oozie, but runs successfully from cli.
I'm supposed to run some jbehave(automated) tests in bamboo. Once the tests run I'll generate some junit compatible xml files so that bamboo could understand the same. All the jbehave tests are ran as part of a script, because I need to run the jbehave tests in a separate display screen(remember these are automated browser tests). Example script is as follows.
Ex:
export DISPLAY=:0 && xvfb-run --server-args="-screen 0, 1024x768x24"
mvn clean integration-test -DskipTests -P integration-test -Dtest=*
I have one more junit parser task which points to the generated junit compatible xml files. So, once the bamboo build runs and even if all the tests pass, I get red build with the message "No failed tests found, a possible compilation error occurred."
Can somone please help me on this regard.
Your build script might be producing successful test reports, but one (or both, possibly) of your tasks is failing. That means that the failure is probably* occurring after your tests complete. Check your build logs for errors. You might also try logging in to your Bamboo server (as the bamboo user) and running the commands by hand.
I've seen this message in the past when our test task was crashing halfway through the test run, resulting in one malformed report that Bamboo ignored and a bunch of successful reports.
*Check the build log to make sure that your tests are indeed running. If mvn clean doesn't clean out the test report directory, Bamboo might just be parsing stale test reports.
EDIT: (in response to Kishore's links)
It looks like your task to kill Xvfb is what is causing the build to fail.
18-Jul-2012 09:50:18 Starting task 'Kill Xvfb' of type 'com.atlassian.bamboo.plugins.scripttask:task.builder.script'
18-Jul-2012 09:50:18
Beginning to execute external process for build 'Functional Tests - Application Release Test - Default Job'
... running command line:
/bin/sh
/tmp/FUNC-APPTEST-JOB1-91-ScriptBuildTask-4153769009554485085.sh
... in: /opt/bamboo-home/xml-data/build-dir/FUNC-APPTEST-JOB1
... using extra environment variables:
<..snip (no meaningful output)..>
18-Jul-2012 09:50:18 Failing task since return code was 1 while expected 0
18-Jul-2012 09:50:18 Finished task 'Kill Xvfb'
What does your "Kill Xvfb" script do? Are you trying something like pkill -f "[x]vfb"? pkill -f silently returns non-zero if it can't match the expression to any processes.
My solution was to make a 'script' task:
#!/bin/bash
/usr/local/bin/phpcs --report=checkstyle --report-file=build/logs/checkstyle.xml --standard=PSR2 ./lib | exit 0
Which always exits with status 0.
This is because PHP code sniffer return exit status 1 when only 1 coding violation (warning / error) is found which causes the built to fail.
Turns out to be a simple fix.
General bamboo behavior is to scan the entire log and see for any failure codes(1). For this specific configuration i had some 6 scripts out of which one of them was to kill the xvfb(frame buffer). For some reason server is not able to kill xvfb and that task was returning a failure code. Because of this, though all the tests passed, bamboo got one of this error codes from previous tasks and build was failing.
Current fix is to remove the task which kills xvfb and the build went green! \o/.