I want to verify if a certain crontab works properly. I have added a job like this:
*/2 * * * * /path_to_my_php_script/info.php >/dev/null 2>&1
I know that i redirect to the null device, but i not sure if the above command is good.
*Edit 1: In my /var/log/syslog every two minutes i have the following error:
(CRON) error (grandchild #2788 failed with exit status 2)
*Edit 2: No errors in logs with this new job:
*/2 * * * * /usr/bin/php /path_to_my_php_script/info.php >/dev/null 2>&1
Although very rare, sometimes cron stops working properly even though the service is running. Here is how to verify that crond is running and stop/start the service.
Using systemctl:
systemctl status cron
systemctl restart cron
Older methods:
On CentOS and other Red Hat-based systems:
service crond status
service crond stop
service crond start
On Ubuntu and other Debian-based systems:
service cron status
service cron stop
service cron start
The syntax for the crontab entry looks correct. Indeed, if you edit your crontab using "crontab -e" (as you should), you'll get an error if you specify a syntactically invalid crontab entry anyway.
Firstly, does /path_to_my_php_script/info.php run correctly from the command-line?
If so, does it also run correctly like this?:
/bin/sh -c "(export PATH=/usr/bin:/bin; /path_to_my_php_script/info.php </dev/null)"
If that works, does it work like this?
/bin/sh -c "(export PATH=/usr/bin:/bin; /path_to_my_php_script/info.php </dev/null >/dev/null 2>&1)"
Step (3) is similar to how cron will run your program (as documented in "man 5 cron".
The most likely problem you're having is that the PATH cron is using to run your program is too restrictive. Therefore, you may wish to add something like the following to the top of your crontab entry (you'll need to add in whatever directories your script will need):
PATH=~/bin:/usr/bin/:/bin
Also note that cron will by default use /bin/sh, not bash. If you need bash, also add this to the start of your crontab file:
SHELL=/bin/bash
Note that both those changes will affect all the crontab entries. If you just want to modify these values for your info.php program, you could do something like this:
*/2 * * * * /bin/bash -c ". ~/.bashrc; /path_to_my_php_script/info.php"
It's also worth mentioning that on a system configured for "mail" (in other words a system which has an MTA configured [sendmail/postfix/etc]), all output from crontab programs is sent to you via email automatically. A default Ubuntu desktop system won't have local mail configured, but if you're working on a server you can just type "mail" in a terminal to see all those cron mails. This also applies to the "at" command.
Do not redirect error output to /dev/null and grep /var/log/syslog for cron output.
grep cron /var/log/syslog
You can immediately show errors when saving a file after editing /etc/crontab or files inside /etc/cron.d/ with:
tail -f /var/log/syslog | grep --line-buffered cron
If the edit is ok, you will only see the RELOAD notice, errors will occur like
Jul 9 09:39:01 vm cron[1129]: Error: bad day-of-month; while reading /etc/cron.d/new
You can see your active cron with the terminal command:
crontab -l
Here are the parameters in order:
min (0 - 59)
hour (0 - 23)
day of month (1 - 31)
month (1 - 12)
day of week (0 - 6) (Sunday=0)
command
So, you are calling your script every first minute of each hour. You should test your output at a more often interval for testing purpose:
* * * * * <command> #Runs every minute
This will call it every minute!
Old question and many complicated answers. The easiest way is to add this line to your crontab
* * * * * /bin/bash -l -c 'date > ~/cron-test.txt'
It will simply every minute write the current date to the file ~/cron-test.txt
Then you just run cat ~/cron-test.txt and check if the shown date is the current date. If it is crontab is working correctly.
For the time part on each line, you can use this cron tester to test/verify your cron time definition.
I believe you can also use run-parts to run cron jobs out of band. It is actually what cron uses itself to run the periodic cron jobs, so by supplying the appropriate arguments you can run them at any time.
If you just want to run one file instead of all the cron jobs defined in eg /etc/cron.daily you will have to supply the regex argument along with a valid regex. run-parts --list --regex '^p.*d$' /etc
Keep in mind that cron jobs are typically named without an extension and marked as executable, so make sure your scripts are similar, though using a regex may allow you to trigger a script with an extension.
First of all, you have to check the cronjob status :
systemctl status cron
after that, run this command in the shell :
crontab -e
and add this line to crontab:
* * * * * /bin/bash -l -c 'date >> /tmp/cron-test.txt'
this command writes the current date every minute in the cron-test file, you can watch the crontab output with the following:
cat /tmp/cron-test.txt
you should have an output like this after 4 minutes :
Mon Mar 6 11:55:01 UTC 2023
Mon Mar 6 11:56:01 UTC 2023
Mon Mar 6 11:57:01 UTC 2023
Mon Mar 6 11:58:01 UTC 2023
now, if you can see this output your crontab works well, else you can see your log and find your issue's reason
grep cron /var/log/syslog
done.
ah !!
got the answer myself, I checked and did not find crond inside the default installation directory i.e /etc/init.d/
will now try and reply.
note -- I did check the cron.allow, cron.deny too. All is fine so far.
