Author: Joe Barr
Most distributions take advantage of that fact to schedule recurring maintenance jobs to be run while you’re least likely to be around. Things like trimming system log files, for example. Otherwise they might eventually fill every byte of available disk space. That’s where cron and crontab come in, and that’s our topic for the week.
Cron is started at boot time, when it gathers up all the entries in the various system and user-level crontab files it knows about and loads their contents in memory. From then on, cron awakens once a minute to see if any of those tasks are due to be run at the current minute, hour, day of month, month of year, or day of week. Crontab is the program which is used to to create and to modify those various crontab files. Crontab has to be run before cron knows about any changes you may make to a crontab file.
On my Debian-based Libranet desktop system, there are ten scripts in /etc/cron.daily, four in /etc/cron.weekly, and two in /etc/cron.monthly. Cron knows to run them because there are entries for them in the system-wide /etc/crontab file.
Each entry in a crontab file describes exactly when a task should run. It also includes the command to be executed by cron at that time.
The basic elements defining the time of execution are (in order of appearance on the line) as follows:
- minute of the hour (0-59)
- hour of the day (0-23)
- day of the month (1-31)
- month of the year (1-12)
- day of the week (0-7) Note: both 0 and 7 indicate Sunday
In /etc/crontab, those arguments are followed by the user and the command to be executed. The /etc/crontab is unique in that all the other crontab files omit the user field.
An asterisk in a field means every — on any — possible value for the field. Effectively, it removes the test for that field.
The first line in the cron entries shown below, the one which executes the ten scripts in cron.daily, is executed at 6:25 every day of the month, every month of the eyar, and every day of the week. The scripts in cron.weekly are run at 6:47 on Sundays, any day of any month. And the monthly jobs are run at 6:52 on the first day every month.
25 6 * * * root test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily
47 6 * * 7 root test -e /usr/sbin/anacron || run-parts --report /etc/cron.weekly
52 6 1 * * root test -e /usr/sbin/anacron || run-parts --report /etc/cron.monthly
Creating your personal user crontab
To schedule your own tasks to be executed by cron, you use a slightly different format for the entries, and you keep them in a different file and location. Entries for individual users are kept files bearing the name of the user in /var/spool/cron/crontabs. My entries, for example, would live in /var/spool/cron/crontabs/joe.
But you can’t just use your favorite editor and create your crontabs file. You have to use the crontab program for that. What you do is create a file someplace else, in your home directory, for example, containing the entries for cron, then enter the command “crontab name-of-your-file”. The crontab program will create or recreate the “official” crontab for you.
Let’s say you want to hear a bell chime at the beginning of each hour. You also want a reminder ten minutes before your weekly status meeting, which is held at 10AM each Monday. Here are the entries you would create in your unofficial crontab file:
0 * * * * play bell.wav
50 9 * * 2 play meeting-time.wav
Maintaining your personal user crontab
You have two choices for adding, removing, or modifying your crontab entries once it has been created. You can keep the “unofficial” crontab file you fed to crontab to create the official version, make whatever changes you have to it, and then reload it in its entirety using the same command you did to create it in the first place.
You can also use the “-e” argument with the crontab command. That will open the default editor on your system with the existing crontab entries in place so that you can edit as you see fit and then save. When you close the editor, crontab will take over again and recreate your “official” crontab file based on the edits you’ve done.
If you know what your default editor is (it’s vi on my desktop) and it doesn’t make you crazy to use it, using this method will give you one less file to worry about. On the other hand, if you don’t know vi already, it’s probably easier just to keep the unofficial crontab file around and use an editor you’re comfortable with.
As always, check man cron and man crontab (and man 5 crontab) for additional information. I hope you paid attention, because next week there will be a test.
