Well, it looks like
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 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 )
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
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 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
crontab. You have now been redpilled on this system and what it’s about. You’re welcome.