WTF?! My cronjob doesn’t run?!
Here’s a checklist guide to debug not running cronjobs:
- Is the Cron daemon running?
- Run
ps ax | grep cron
and look for cron. - Debian:
service cron start
orservice cron restart
- Is cron working?
* * * * * /bin/echo "cron works" >> /tmp/file
- Syntax correct? See below.
- You obviously need to have write access to the file you are redirecting the output to. A unique file name in
/tmp
which does not currently exist should always be writable. - Probably also add
2>&1
to include standard error as well as standard output, or separately output standard error to another file with2>>/tmp/errors
- Is the command working standalone?
- Check if the script has an error, by doing a dry run on the CLI
- When testing your command, test as the user whose crontab you are editing, which might not be your login or root
- Can cron run your job?
- Check
/var/log/cron.log
or/var/log/messages
for errors. - Ubuntu:
grep CRON /var/log/syslog
- Redhat:
/var/log/cron
- Check permissions
- Set executable flag on the command:
chmod +x /var/www/app/cron/do-stuff.php
- If you redirect the output of your command to a file, verify you have permission to write to that file/directory
- Check paths
- Check she-bangs / hashbangs line
- Do not rely on environment variables like
PATH
, as their value will likely not be the same under cron as under an interactive session. See How to get CRON to call in the correct PATHs
- Don’t suppress output while debugging
- Commonly used is this suppression:
30 1 * * * command > /dev/null 2>&1
- Re-enable the standard output or standard error message output by removing
>/dev/null 2>&1
altogether; or perhaps redirect to a file in a location where you have write access:>>cron.out 2>&1
will append standard output and standard error tocron.out
in the invoking user’s home directory. - If you don’t redirect output from a
cron
job, the daemon will try to send you any output or error messages by email. Check your inbox (maybe simplymore $MAIL
if you don’t have a mail client). If mail is not available, maybe check for a file nameddead.letter
in your home directory, or system log entries saying that the output was discarded. Especially in the latter case, probably edit the job to add redirection to a file, then wait for the job to run, and examine the log file for error messages or other useful feedback. - If you are trying to figure out why something failed, the error messages will be visible in this file. Read it and understand it.
Still not working? Yikes!
- Raise the cron debug level
- Debian
- in
/etc/default/cron
- set
EXTRA_OPTS="-L 2"
service cron restart
tail -f /var/log/syslog
to see the scripts executed
- in
- Ubuntu
- in
/etc/rsyslog.d/50-default.conf
- add or comment out line
cron.* /var/log/cron.log
- reload logger
sudo /etc/init.d/rsyslog restart
- re-run cron
- open
/var/log/cron.log
and look for detailed error output
- in
- Reminder: deactivate log level, when you are done with debugging
- Run cron and check log files again
Cronjob Syntax
# Minute Hour Day of Month Month Day of Week User Command
# (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)
0 2 * * * root /usr/bin/find
This syntax is only correct for the root
user. Regular user crontab
syntax doesn’t have the User field (regular users aren’t allowed to run code as any other user);
# Minute Hour Day of Month Month Day of Week Command
# (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)
0 2 * * * /usr/bin/find
Crontab Commands
crontab -l
- Lists all the user’s cron tasks.
crontab -e
, for a specific user:crontab -e -u agentsmith
- Starts edit session of your crontab file.
- When you exit the editor, the modified crontab is installed automatically.
crontab -r
- Removes your crontab entry from the cron spooler, but not from crontab file.