I have a cron job on an Ubuntu 10.4 server that stopped running for no apparent reason. (The job ran for months and has not been changed.) I am not a *nix guru so I plead ignorance if this is a simple problem. I can't find any reason or indication why this job would have stopped. I've restarted the server without success. Here's the job:
# m h dom mon dow command
0 * * * * java -jar /home/mydir/myjar.jar >>/home/mydir/crontaboutput.txt
The last line in the output file shows that the program ran on 8/29/2012. Nothing after that.
Any ideas where to look?
There should be something in your system log when the job was run. The other thing you could >try is to add 2>&1 to the job to see any errors in your text file. – Lars Kotthoff yesterday
This proved to be the key piece of information - adding 2>&1 allowed me to capture an error that wasn't getting reported anywhere else. The completed command line then looked like:
java -jar /home/mydir/myjar.jar 2>&1 >>/home/mydir/crontaboutput.txt
Perhaps your cron daemon has stopped, or changed configuration (i.e. /etc/cron.deny). I suggest to make a shell script, and running it from crontab. I also suggest to run thru your crontab some other program (just for testing) at some other time. You can use the logger command in your shell script for syslog. Look into system log files.
Accepted answer is correct, (i.e, check the error logs) which pointed out the error in my case. Besides check for the following issues
include('../my_dir/my_file.php) may work from url but it will not work when cron job is run, will spit out error.
$_SERVER variables does not work inside cron os if you are using $_SERVER['DOCUMENT_ROOT'], it will not be recognized and you will have an error in the cron job.
Make sure to test the cron and have it run, send an email etc to make sure it is run.
Related
I've sucessfully configured a script that scans my system using cron in a scheduled hour of a day. However, I would like to see the results that it might have generated with its execution. Ex: rkhunter -c leaves logs in /var/log/rkhunter.log that I manually would have to check after it performed the task.
How can I configure cron to show a terminal with its results for example?
I've seen a similar case to mine, but it didn't work:
minute hour * * * DISPLAY=:0 xterm -e /dir_to_my_script/script.sh
But it gave the following error that I've not been able to solve so far:
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s
Is there a way to accomplish it using cron as root? Thanks
I am planning to run some bash scripts every minute, and I wrote:
* * * * * bash ~/Dropbox/temp_scripts/run_all_scripts
in crontab.
It was supposed to run every minute, but it did not work. Does anyone have idea why this happens?
Transferring a comment into an answer.
Add I/O redirection to the command line in the crontab entry:
>/tmp/run_all_scripts.out 2>/tmp/run_all_scripts.err
Review the contents of the files after a minute or two has passed. Consider recording the environment to see if that's part of the problem. And consider using bash -x instead of just bash.
If you still don't get anything (the files in /tmp are not created), then you've got issues with cron; the daemon isn't running, or your user does not have permission to use it (but crontab isn't telling you that), or you've not submitted your crontab to the program (what does crontab -l say?), or … whatever is really wrong.
Note, too, that the output from cron jobs is normally (well, at least sometimes — on Mac OS X for a system I currently use, and Solaris for another that I've used previously) emailed to the person whose job it is. You should review the email on the system.
Thank you! I have already fixed it! The reason why it does not work is I used "ls -a .sh" in the script, and when the crontab did not find any *.sh files in the folder it was executing. When modifying it to "ls -a $HOME/Dropbox/temp_scripts/.sh", everything works! This debugging technique is quite helpful!
It is, in many ways, the most basic of debugging techniques — make sure you see what is actually happening. If you're not sure why a shell script isn't working, make sure you can see that it is executing and what it is producing in the way of output, and (very often) make sure you can see what it is executing with bash -x or equivalent. (AFAIK, all shells support -x to trace the execution.)
I cannot find documentation on how to set up Cron commands for some reason. Here's my current Cron command using GoDaddy's cron job manager tool. It runs twice an hour.
/web/cgi-bin/php5 "$HOME/~path-to-file~/my-function.php" > "$HOME/~path-to-file~/my-function.log"
What I'd like to do is get a thorough log of each time the Cron runs - output, timestamp, etc. I'm trying to debug this script and I'm stuck without some kind of error logging.
Thanks all!
You are directing Standard Output to the specified file by >, but Standard Error gets sent into oblivion. Add 2>&1 to the end of the command to append any errors to the same file.
/web/cgi-bin/php5 /path/to/php > /path/to/logfile.log 2>&1
I tried a lot of methods but ended up with nothing in hand..My simple target is to reset a variable to zero at the end of the day.
i checked the location of php as "which php" and "whereis php"
which resulted into /usr/bin/php
here are some of things i tried..
/usr/local/bin/php -f /home/USERNAME/public_html/developer3/crons/filename.php
/usr/bin/php -f /home/USERNAME/public_html/developer3/crons/filename.php
php -q /home/USERNAME/public_html/developer3/crons/filaname.php
/usr/bin/wget -O http://subdomain.sitename.com/crons/filename.php
for quick results, i kept the timming as every minute to execute the code. i could successfully execute the code as
http://subdomain.sitename.com/crons/filename.php
please guide me.
If the path to php on your system is /usr/bin/php then the command you should be running with cron should be
/usr/bin/php /full/path/to/php/script.php
Is the script you're running designed to be invoked from the php-cli in that way? If it isn't and works correctly when you use a browser then you can use curl, if it's installed on your server
curl -A cron-job http://subdomain.sitename.com/crons/filename.php
It would likely be helpful in any event to configure the MAILTO variable (since you're using cPanel, it's just a text box on the appropriate page that you can fill in) so that you get an email with the output from your cron jobs. Having the output emailed to you will help you diagnose what's causing your script to not have the desired effect when it runs.
I'm struggling trying to debug a cron job which isn't working correctly. The cron job calls a shell script which should unrar a rar file - this works correctly when i run the script manually, but for some reason it's not working via cron. I am using the absolute file path and have verified that the path is correct. Has anyone got any ideas why this could be happening?
Well, you already said that you have used absolute paths, so the number one problem is dealt with.
Next to check are permissions. Which user is the cron job run as? Does it have all the permissions necessary?
Then, a little trick: if you have a shell script that fails and it's not run in a terminal I like to redirect the output of it to some files. Right at the start of the script, add:
exec &>/tmp/my.log
This will redirect STDOUT and STDERR to /tmp/my.log. Then it might also be a good idea to also add the line:
set -x
This will make bash print which command it's about to execute, and at what nesting level.
Happy debugging!
The first thing to check when cron jobs fail is to see if the full environment is available to the script you are trying to execute. In other words, you need to realize that a job executed via cron runs as a detached process meaning it is not associated with a login environment. Therefore whenever you try to debug a cron job that works when you execute manually, you need to be sure the same environment is available to the cronjob as is available to you when you execute it manually. This include any PATH settings, and other envvars that the script may depend on.
For me, the problem was a different shell interpreter in crontab.