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 cronand look for cron. - Debian:
service cron startorservice 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
/tmpwhich does not currently exist should always be writable. - Probably also add
2>&1to 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.logor/var/log/messagesfor 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>&1altogether; or perhaps redirect to a file in a location where you have write access:>>cron.out 2>&1will append standard output and standard error tocron.outin the invoking user’s home directory. - If you don’t redirect output from a
cronjob, the daemon will try to send you any output or error messages by email. Check your inbox (maybe simplymore $MAILif you don’t have a mail client). If mail is not available, maybe check for a file nameddead.letterin 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 restarttail -f /var/log/syslogto 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.logand 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.