I have a ridiculously simple shell script, nothing more than a few instructions to run some php files ...
#!/bin/bash
clear
cd /home/************** // Just for privacy here
php cron-cpt.php
php cron-lvt.php
php cron-plots.php
php cron-m.php
php cron-a.php
The script is called metrics.sh which is chmod'd and just sits in my local binary folder.
If I run the script from the command line, it works perfectly.
If I add the same script to the cron tab to run once a day, it runs over and over. I assumed the cron was the same as invoking it manually from the command line?
I'm using the same user to invoke in cron as logged on cmd line and have tried as root and a standard user, but the same results prevail.
Google has not been helpful with this. Any suggestions?
Add this to your cronTabs:
0 1 * * * /home/metrics.sh
Change the location to your metrics.sh's location.
Related
i want to set a cron job on a server but its not working. I know there are hundreds of links on web that shows how to setup a cron job but i cant seem to make it work. What im doing now is:
1) Running crontab -e.
Then it shows bunch of lines in the command line.
2) I go to the bottom and add */5 * * * * path/to/myfile.php
and then i exit the editor in command line. Please tell me whats wrong here. Do i need to put my file in a specific folder? or do i need to go to the desired folder and then use crontab -e, or something else. Please forgive me, this is my first cronjob, hoping to be better next time.
Here are the pictures of what im doing.
Did you restart the cron service after you updated the file?
Have you tried executing the php script from the command line first to verify that it's executing as expected? It might be that the cron task is executing but the script is failing. If the script is fine, you might want to try using php as a command followed by the path and filename of the php file and then quitting the execution after it's done with -q.
*/5 * * * * php path/to/myfile.php -q
The problem could well be that you are trying to execute a PHP file and your system is unaware of what to do with it.
Is your PHP file executable?
You can make it executable by running
$ chmod +x file.php
and if you add a shebang to it
#!/usr/bin/php
<?php
// ...
the PHP script can be executed by running
$ ./file.php
Alternatively, you need to run the PHP interpreter and pass it the path to the file as an argument.
$ php file.php
For reference, see:
http://php.net/manual/en/features.commandline.usage.php
I need your help here.
I wrote one PERL script for PHP application which needs to be run for every 5 mins.
This script will call PHP program, which will fetch data from MySQL DB and will generate a excel report and will mail those reports to specific users.
Every thing seems to be fine when I ran this script manually with the command (perl reports.pl).
But when I set this Perl in a cron tab, nothing works and reports are not getting generated.
Details: perl script path /opt/app/deweb/web/EDI/Microsoft/reports.pl
this script will call PHP program (/opt/app/deweb/web/EDI/Microsoft/reports.php)
content of script
#!/usr/local/bin/perl
use Net::FTP;
use File::Copy;
use POSIX;
#errorreport = `php /opt/app/deweb/web/EDI/Microsoft/reports.php`;
print "#errorreport\n";
exit;
It is working perfectly when running Manually using command - perl reports.pl
No results, when set in CRON:
*/5 7-19 * * * /usr/local/bin/perl /opt/app/deweb/web/EDI/Microsoft/reports.pl
Please note that this crontab is under super user account named webserv and my login is having access to edit under this super user account.
I'm editing this cron tab using command :: sudo -u webserv crontab -e
I would check the following:
Does it run using sudo -u webserv perl reports.pl? If not, fix the problem for the webserv user (permissions or whatever) and it should work via cron too.
Does which perl using your login give you /usr/local/bin/perl? If not, change the path to Perl in crontab to what you got in which perl to fix the problem.
I found myself to be in the same situtation. After trying to find out the reason, I am almost sure about the reason this happens. Crontab does not have the same environment variables as you when running the script. You must be sure about paths. Try for example run your script like /perl-path /path-to-perl-script/script.pl outside the parent directory of the script and I am almost sure that your programm will not find some files. And as you call one php script from the perl script, it's possible to have the same problem with paths to your php script too.
So the solution is to use absolute paths and no relative.
Also at your perl script don't use php but /full-path-to-php for example:
#errorreport = /usr/bin/php /opt/app/deweb/web/EDI/Microsoft/reports.php;
I'm trying to implement a testing integration solution in our environment. The simple workflow is like this: I have a CentOS EC2 instance in AWS where there is a MySQL DB with rows representing tests to be run (each one has a unique id, absolute file path, started time, completed time, etc). These tests are actually python scripts (using unittest framework).
I have created a PHP script (my language of choice) that takes all the non-started tests from the DB and runs them locally using python or even py.test which I execute through shell_exec() in my code.
Before running the PHP script though, I also execute (at least the first time) the following bash script to setup a local testing environment using headless Firefox with WebDriver, Selenium Server and Xvfb for a "display":
#!/bin/bash
if [ `whoami` != "root" ] ; then
echo "Run as root!"
exit 1
fi
#Start X virtual frame buffer
/etc/init.d/xvfb start
#Add fake display to env
export DISPLAY=:99
#Start Selenium Server
java -jar /opt/selenium-server/selenium-server-standalone-2.33.0.jar &
If I run my PHP script from the terminal like this:# php script.php everything runs correctly, php calls shell_exec() which in turns runs python to execute the test through py.test using the fake display etc.
BUT, when I try to add this PHP script in a cron job it fails. My cron.d file looks like this:
* * * * * root /usr/bin/php /path/to/script.php >> /path/to/log.log
I have read online that a solution would be to create a shell script that will call the PHP script inside it and put that into cron instead. I tried that and it seemed to do something but it stuck in another place (in my shell script first of all I had export DISPLAY=:99 just in case, so the python script will see the virtual display but I'm not sure if needed).
Anyway, following the above road, somehow made py.test to execute but then it throws an exception when it tries to locate the Firefox binary (which is located at /usr/local/bin/firefox). It seems that the shell script cannot see the $PATH. But I have also read the following: a shell script that executes another script inside it (PHP in our case) actually spawns a child for this, so is not always true that this child can see the $PATH even if set on the parent script? I'm not sure about this.
Can you help me? What's the best way to have all of the above run in cron?
How to make the PHP or shell script see the $PATH? (if that's the way to go at least)
You can export PATH in the beginning of your cron command.
Find the correct PATH
$) echo $PATH
/some/path:/some/other/path
In your crontab, write
* * * * * export PATH="/some/path:/some/other/path" && /usr/bin/php /path/to/script.php >> /path/to/log.log
Alternatively, you can set it in the beginning of your crontab file as well as shown here
Since you are setting the value of the DISPLAY environment variable and starting the xvfb sever, you should consider setting the path as well within your shell script and run the shell script as the cron job (instead of the php script I use in my example)
Create a crontab job from root user and remove root from: * * * * * root /usr/bin/php /path/to/script.php >> /path/to/log.log.
Description: I am not very familiar with using a lot of bash/shell. I currently have a cron tab set up on an Ubuntu server that runs a Shell script. The Shell script then is suppose to run a PHP script, however, instead I am getting the following error message:
Could not open input file: wscript.php
At the top of my shell script I have written #!/bin/bash
Then the shell script itself I am passing a bash variable to PHP script.
while read bashvariable
do
php wscript.php "$bashvariable"
done
Keep in mind when I run this this shell script manually the script executes and fires correctly.
At the top of wscript.php I have placed in #!/usr/local/bin/php.
wscript.php has an include file of wscript-add.php
I have attempted to change the permission of all files to 777 and I haven't had any luck on getting the cron tab to run correctly.
Below is what my cron tab looks like:
*/2 * * * * sh /var/www/website/wcron/wcron.sh
My Question: What could cause my PHP file to not fire correctly when used by cron? Do I need specific file permissions on each file to run correctly?
You need to specify full path to php script as when cron runs, it uses different current directory.
I have a PHP script that runs perfectly fine on the command line if I simply run it like this php /path/to/script/script.php.
if I now schedule this very command in cron using crontab -e and the add the line:
*/1 * * * * php /path/to/script/script.php 2>&1 >> /var/log/logfile.log
it does get executed every minute as expected and all the output gets put into the log file just like running it on the command line. But the some parts of the script just don't seemt o work. those particular parts are lines that are like:
system('mkdir /mnt/temp', $retVal);
or
exec('mkdir /mnt/temp');
I have tried every possible thing like running it as root, permissions on all scripts and folders that would be affected, using /bin/mkdir instead of mkdir. The return value from the system() is 0 for running it on CLI and 1 for the crontab way.
Any suggestions?
I couldn't solve the CLI vs crontab issue, but the solution that worked for me was to use a bash script inside of cron. And that bash script in turn calls the PHP script. this works like a charm under any of the users that I need to run the script.
So I can't say that it is or isn't a permissions issue.
Thanks for all your comments guys