I have the following CRON configuration:
crontab -l
* * * * * curl http://x.com/script.php
But it just doesn't work. The command "curl http://x.com/script.php" triggered manually works
all fine so it's obviously something wrong with CRON. What could go wrong?
From the top of my head, 'curl' is not in the PATH, when cron is trying to execute it. Type its absolute path, or use the PATH variable in the crontab. If that doesn't help, I would check if /usr/sbin/cron is running. If it is, also check permissions of /var/cron/tabs/ and its contents, and check the log file /var/log/cron for any suscpicious errors.
Related
I want to run the below via Crontab job and not working but when put them in sh file and run the sh manually it works fine.
Sh file path: /opt/etc/rt4/test.sh and the content as below:
wsgetmail --config=account01.json
wsgetmail --config=account02.json
Running manually:
sh /opt/etc/rt4/test.sh it works fine.
Crontab:
*/1 * * * * /opt/etc/rt4/test.sh
Crontab runs this file but those commands are not working.
I have other Crontab jobs and they are working fine as intended.
The crontab and terminal are two different environments, the wsgetmail perl module command is recognizable for terminal but to make it recognizable for corntab we have to add the full path to the module (wsgetmail) in the shell script.
in this case test.sh should looks like this:
#!/bin/bash
/usr/local/bin/wsgetmail --config=account01.json
/usr/local/bin/wsgetmail --config=account02.json
Running manually: sh /opt/etc/rt4/test.sh it works fine.
Crontab: */1 * * * * /opt/etc/rt4/test.sh
Those are not the same thing, as 1st line shebang, and chmod a+x test.sh, will affect the behavior.
Either remove "sh" when running manually, or prepend it to the cron command.
Run $ id, and determine if that's different
from how the cron command runs, perhaps by
having cron log id output.
Running as yourself manually,
versus as root (uid=0) under cron,
can change the behavior of that command.
Numerous other things are different
under cron, such as lack of a pty.
Take a look at $ env | sort manually.
Then run it under crond, and note the huge difference.
Pay special attention to PATH.
It is likely to be much shorter under cron,
and that can lead to "command not found"
diagnostics.
But you chose not to share any diagnostic
error messages with us,
so coming up with a definitive diagnosis
of this amounts to a mind reading exercise.
I want to run a crontab every 15minutes. I tried this:
0 */15 * * * ./usr/My_PATH/run.sh
But I get this error:
0 command not found
Is there something wrong with the syntax ?
Many thanks.
UPDATE:
I corrected the script and I tried this:
*/15 * * * * /My_Path/run.sh
and this
0,15,30,45 * * * * /My_Path/run.sh
In both cases I get an error.
#1 bash: */15: No such file or directory
#2 bash: 0,15,30,45 command not found
If this:
0 */15 * * * ./usr/My_PATH/run.sh
fails with this error:
0 command not found
then you're trying to run it as a shell command. You need to feed it to the crontab command. There are several ways to do this.
crontab -l will list the current contents of your crontab; it doesn't modify it.
crontab -e will open (a copy of) your crontab in a text editor and let you modify it. This is probably the simplest way to update it.
crontab filename reads the specified file and replaces your current crontab with its contents. (If you already have a crontab, this will quietly clobber it.)
The method I recommend is to keep a separate file containing your crontab (say, crontab.txt).
First, if you already have a non-empty crontab (check with crontab -l), save it to the file:
crontab -l > crontab.txt
Make whatever additions or other changes you want to that file, and then use
crontab crontab.txt
to install the updated crontab.
You can keep backup copies (I maintain mine in a source control system) so you can recover if you mess something up. And you can do a quick crontab -e if you want to test something, then re-run crontab crontab.txt to revert to the stored crontab.
The syntax of the crontab line in your question:
0 */15 * * * ./usr/My_PATH/run.sh
is correct, but the path ./usr/My_PATH/run.sh looks like it may be incorrect. Cron jobs run from your home directory, so the path is valid only if the usr directory is directly under your home directory (and in that case the ./ is unnecessary). It's probably better to specify the full path, which can start with $HOME/.
Yes.
First field is minutes. Second field is hours. You're setting it off at zero minutes past the hour, every 15th hour. So basically - 15:00 each day.
You want:
*/15 * * * * /some_script
Furthermore - ./ - it's a relative path, and that's probably a bad idea with cron, because it doesn't chdir to run stuff. Use an absolute path to avoid confusion. If you absolutely need to be in a particular directory for the script to work, you can try:
cd /path/to/script && ./this_script
So it's quite possible that you've got broken permissions or just not finding a relative path that you're using.
I have added a script in crontab for every 30 minutes. The line goes as follows:
*/30 * * * * root perl /root/perl.pl
The above script has a execution of system command 'top' and it gets printed in a log file.
If I run it manually it runs fine. But while running it via crontab, it does not show up the desired results. Please can somebody help me with this. Thank you.
The command in the above perl script is:
$top = `sudo top`;
The error I am getting is:
sudo: sorry, you must have a tty to run sudo
I changed my command from sudo to visudo. But still the problem remains.
You should use the full path in cron (and use which perl to find the full path):
*/30 * * * * root /usr/bin/perl /root/perl.pl
OR better yet, make the script executable using chmod +x, and add the interpreter to the beginning of the script #!/usr/bin/perl -w and call it directly from cron
*/30 * * * * root /root/perl.pl
Also if there is a problem in the perl script, you could output the result from cron like this
*/30 * * * * root /root/perl.pl > /tmp/myscript.log
You should look into the requiretty setting with regard to visudo. Look for a line that reads Defaults requiretty. You could try commenting it out, but you will be sacrificing some security. See man sudoers.
You could also try running top in batch mode with one iteration:
$top = `sudo top -bn1`;
Batch mode option is for sending output to other programs.
I am trying to to run a cronjob of a script on an EC2 Instance but it's simply not working
The way I am running it right now is
15 * * * * root /home/ec2-user s3_upload.sh TestBucket
I wrote this when I did crontab -e
Right now I am in this directory /home/ec2-user/ so I don't know if maybe that has something to do with why it's not running.
I just don't understand this whole cron thing and how permissions work.
Any help is greatly appreciated!
You can't specify a username in a user's crontab, only in /etc/crontab.
You can't specify a directory in any form of crontab. To change directory, use cd.
The environment is not the same. If you e.g. set PATH in .bashrc, these will not be automatically included, so it's safest to use full paths.
As root (assuming you want to run this as root and not ec2-user or something), run crontab -e and add
15 * * * * cd /home/ec2-user && /full/path/to/s3_upload.sh TestBucket
Make sure you can copy-paste the command in a root terminal and get it working, and read root's mail afterwards to see the command's output with possible error messages. If it still doesn't work, make sure you have these errors available.
i have this crontab,
* * * * * php /etc/raddb/overloaded.php
but it is not running fine, meaning it doesnt run every minute, but when i manually enter this into the terminal (php /etc/raddb/overloaded.php), the script works
thank you guys
PS: im using centos 32 bit. also im using the "crontab -e" to insert and save crontab, but it looks like that crontab is not running? i typed "crontab -e" and yet (* * * * * php /etc/raddb/overloaded.php) appears. where is the issue here? thanks
Crontab syntax is right. Please check if your cron daemon is running and you can check log, maybe it conatins some usefull info.
I think the most possible problem is that cron has its own environment settings. Try to run php with its full path, e.g.
/sbin/php
or w\e path you have