Source: This SO Answer
- Is the Cron daemon running?
- Run
ps ax | grep cron
and look for cron. - Debian:
service cron status
, if not running,service cron start
orservice cron restart
- Run
- 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.
- 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
- 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
- Set executable flag on the command:
- 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
- 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.
- Commonly used is this suppression:
- 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.crit /var/log/cron.log
- Reload logger
sudo /etc/init.d/rsyslog reload
- Re-run cron
- Open
/var/log/cron.log
and look for detailed error output
- In
- Debian
- Reminder: deactivate log level, when you are done with debugging
- Run cron and check log files again
# 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 -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.
Courtesy: Jens A. Koch
Here is another gotcha to watch out for: I found that I had to embed commands in a script and call that, alos take note of using /bin/sh and using full path names for commands, then I got the results I expected. Before that everything looked fine and the job ran but my custom updatedb.plocate jobs were producing no output (updated indexes on disk) despite the same command running fine from a bash prompt.