Well, it looks like cron
/crontab
administration is trending in the Linux community on WordPress for some reason, and just my luck, because I happen to be a crontab
veteran, having played with this program extensively back in 2010 when I was first learning Unix. It would be foolish, then, for me to not exploit this trend, and so here I am with all the answers once again. In this tutorial I will tell you everything you will ever need to know about the cron
daemon. Let’s dive right in…
First of all, let’s establish exactly what cron
is. cron
is a job scheduling daemon. That means it’s running at all times by default, from the moment you boot up to the moment you shut down, and it runs scheduled commands without user intervention. You give it jobs to run (called cron jobs) via a special file called the crontab
file, which specifies the command as well as some numerical parameters that tell cron
exactly when you want that command run, and it will run the specified command at the specified time. As far as understanding cron
is concerned, that’s pretty much all you need to know. Though that doesn’t mean there isn’t a wealth of additional knowledge to be gained about this neat little daemon.
First thing’s first. Make sure you have a cron
instance running by typing the following command at the terminal:
$ ps -A | grep cron
If you don’t see a cron
process running, start it by typing sudo cron
at the command line.
Let us now look at the crontab
file. The first thing you should know about this file is that it doesn’t actually exist on your permanent filesystem. Instead, the crontab
file is a temporary file that is generated on-the-fly from input given to the crontab
program by users via the command crontab -e
. This command will open your personal list of cron
jobs in your default text editor (the one specified by the EDITOR
environment variable set in your startup script). You then enter the cron jobs in the text editor, and they are sent to cron
when you save and exit the text editor.
The format of the crontab
file will look familiar to anyone with a habit of digging through /etc because it has the same flat-file database structure that the passwd file and many of the other config files in that directory have. Each line holds a single record, which is divided into several columns or fields. The first several fields contain numerical parameters that together tell cron
when the job should be run, and the last field tells cron
what command should be run for that job. To illustrate, here is what the system-wide crontab
file looks like on many Linux systems:
1 # /etc/crontab: system-wide crontab
2
3 SHELL=/bin/sh
4 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
5
6 # m h dom mon dow user command
7 17 * * * * root cd / && run-parts --report /etc/cron/hourly
8 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
9 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron/weekly )
10 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
The system-wide crontab
is sort of a dummy file that acts as a proxy of sorts for scheduled jobs stored elsewhere in the system. The input that you would give to crontab -e
would look very similar to this, minus the SHELL
and PATH
variables and minus the user
column. As you can see there are five fields that specify the time to run the command: they are (in order): minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), and day-of-week (0-7). On Linux systems, a DOW value of either 0 or 7 indicates a Sunday. An asterisk indicates that the specified command runs on every minute/hour/day-of-month/etc. If you want something to run for a particular range of time units, use two numbers separated by a hyphen (e.g. dow=1-5
for weekdays).
When deciding how to schedule jobs, the cron
daemon first looks at the system-wide crontab
file. By default this file has four jobs scheduled, and each tells cron
to look in a specified directory for additional crontab
information. It does this by running a command called run-parts
. run-parts
is a script that takes a directory as an argument and runs every script that it finds in that directory. Thus if you want a script to be run whenever cron
runs its hourly cron
jobs, you would place it in the directory /etc/crontab/hourly.
In addition to running these regular jobs, cron
also runs the jobs stored in the crontab
files specific to each user. These files are stored in /var/spool/cron/crontabs. Typically they are not edited directly but are modified indirectly through the crontab
program. There are two standard methods for loading cron
jobs so that cron
will actually run them. One is to run crontab -e
, enter the cron
jobs, then save and exit, and the other is to load a pre-written crontab
file (say crontab.personal) using the command crontab crontab.personal
. The latter method can also be reversed. Type crontab -l > crontab.personal
at the terminal and the cron
jobs currently registered with cron
will be saved to the file crontab.personal.
And so that’s the gist of cron
and crontab
. You have now been redpilled on this system and what it’s about. You’re welcome.