Cron is the most well known way to schedule tasks on a Linux system. It seems like every time I set it up though I always forget a few simple details that result in me wasting an hour of my time!
After a recent 30 minute battle to setup a simple cron job I decided to type some of this up so that this doesn't keep happening!
This is more for of a reference for myself but maybe it will help someone else out there also. So let's jump right into it.
High-level How Cron works
Cron files are just text files where you define a syntax for each command you want run at some specified interval. Each user gets a cron file that can be edited with the crontab command.
Once you add the command to a crontab file you will get a response showing that the crontab file has been installed. Because cron doesn't have an interactive CLI or anything it can be a bit of a chore to set one up if when you do something wrong.
There are also some special folders that if you drop a bash script in them, it will get executed at the interval of time specified by the folders name. I really don't use them though to be honest. I prefer the additional control and options that the crontab files allow.
Quickstart
To edit the crontab file of the current user (This is the best way):
crontab -e
To edit the crontab file of the root user (Needed when you need to execute tasks you could normally only do with sudo):
sudo crontab -e
Add this to your crontab file as a reference:
#* * * * * command to be executed
#- - - - -
#| | | | |
#| | | | +----- day of week (0 - 6) (Sunday=0)
#| | | +------- month (1 - 12)
#| | +--------- day of month (1 - 31)
#| +----------- hour (0 - 23)
#+------------- min (0 - 59)
# Examples:
# Run every 5 min:
# */5 * * * * /home/tim/script.sh
The cron command I like to use
The cron command form I like to use is:
*/15 * * * * /home/tim/script.sh >> /home/tim/script.log 2>&1
-
This command will run every 15 minutes, denoted with the
*/15 -
The
>>is the standard syntax to redirect standard out (appending while you do) to the filescript.log -
The
2>&1ensures that standard error will also be directed into that log file. This is essential for debugging errors.
Troubleshooting cron
The best way I have found to troubleshoot cron is to redirect the results of the script into a log file like I did above and then check the log file for any redirected errors.
Its also great to temporarily set your script up to run every minute so you can debut the issues quicker.
Getting the environmental variables that cron is running with
I found a great suggestion online to try the following first if you are running into issues with a cron job not starting or logging errors:
* * * * * env > /tmp/env.output
Test your cron with the above simple command and then check the resulting file in /tmp/env.output to make sure your environmental variables match up with what you think they are. Often they don't!
Make sure your cron file ends with a new line!
Yes, its annoying but your cronfile must end in a newline. I usually throw in two just to be sure!
Some Common Issues I have had
-
Your paths have been typed wrong. Double check that you didn't make an error in a folder name, etc!
-
Relative paths - Avoid using relative paths. Give the full path to any files you are referencing.
-
Scripts not owned by root - if you are running a script via the root crontab, make sure its owned by the root:
sudo chown root.root somefile -
Script is not executable:
chmod +x /path/to/script -
Cron is not running. Check for it:
service cron status
Changing the default editor from Nano to Vim
I tried changing the environmental variables export EDITOR=vim and export VISUAL=vim but that didn't work for me on Ubuntu.
What did work though is running the command select-editor.
Comments
comments powered by Disqus