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.
Psycho Cod3r 