Linux Training

Linux training for private, public & voluntary sector.

0800 024 8425

City LinUX Training Courses

Section 21.
Scheduling work with cron

21. Scheduling work with cron.

"Note that if I can get you to "su and say" something just by asking, you have a very serious security problem on your system and you should look into it."

Paul Vixie - vixie-cron 3.0.1 installation notes.

Scheduling routine tasks is a very simple using Linux tools common to all releases.

Process which run continuously in the background are called daemons or demons. They commonly enjoy a letter ’d’ appended to the basic name. This is true of the cron daemon, crond and its sibling the at daemon (atd),

The cron daemon runs in the background and executes commands or shell scripts to a schedule set by the user in a crontable or crontab.

The crontables are kept in /var/spool/cron/crontabs. Tables are stored with the user’s login name.

sa101$ sudo bash
sa101$ cd /var/spool/cron/crontabs
sa101$ ls -l
total 4
-rw------- 1 root root       0 Mar  9  2012 adm
-rw------- 1 root fulford    0 Aug 11 12:27 fulford
-rw------- 1 root root    1545 Dec 29 16:27 root

Direct access to the crontabs is normally restricted to root. For ordinary mortals there is the crontab utility which uses the set-uid facility in Linux to change the effective UID when installing a new or modified crontab. With the -l option crontab will list the current content of the users crontab, with the -e flag the crontab will be opened using the users preferred editor as set in the EDITOR or VISUAL environment variables. (If neither are set then the default editor is used, in most releases this will be vi).

sa101$ sudo bash
sa101$ crontab -e
reading /var/spool/cron/crontab.OKnVIu
Read /var/spool/cron/crontab.OKnVIu, 29 lines, 1545 chars
wrote /var/spool/cron/crontab.OKnVIu, 29 lines, 1546 chars
sa101$ ls -l /var/spool/cron/crontabs
total 8
-rw------- 1 root root       0 Mar  9  2012 adm
-rw-r--r-- 1 root root       5 Jan  4 02:57 cron.update
-rw------- 1 root fulford    0 Aug 11 12:27 fulford
-rw------- 1 root root    1545 Jan  4 02:57 root
sa101$ cat /var/spool/cron/crontabs/cron.update

Note that cron.update file that is now in /var/spool/cron/crontab.

The old way of managing crontabs was to take a copy of the crontab file, edit it and copy it back to the spool directory. A SIGHUP (-1) signal would then be sent to the crond process which would cause it to re-read the crontabs. Later versions daemon would re-read any crontab files that had been recently modified automatically.

When using crontab with -e a temporary file is created for the duration of the edit. On exiting from the editor the crontab is written back to the spool directory and the user name is added to cron.update. This file is checked by crond every minute and the listed crontabs are read or re-reread.

The way crond and crontab works differs with the distribution. Both CentOS and Ubuntu for instance use versions derived from the Paul Vixie cron programs, but CentOS’s version is maintained by Marcela Maslanova at RedHat, whereas the Ubuntu offering credits only Paul Vixie but has Debian specific modifications to allow better handling of scripted crontab file changes. Slackware uses the simpler and to my mind more elegant Dillon’s lightweight cron daemon, (dcron), currently maintained by Jim Pryor. Other versions are also available.

21.1. The crontab.

Most cron daemons honour the 6 fields found in Dennis Ritchie’s version of cron that was available for UNIX v7. The Vixie crontab has a 7th field available for the superuser to specify a user id that is to be used when running the command.

Image imgs/sa101-28.png


The minutes field is the number of minutes past each hour. Use an asterisk (*) to indicate that the event should be scheduled every minute. A range of minutes may be indicated with the hyphen e.g. 1-30. A list of minutes past the hour may also be used e.g. 15,25-35,45 forward slash (/) may be used to indicate step values through the hour e.g. 0-50/10 would schedule the event every 10 minutes.


The hour field specifies the hour the job is to be run using the 24 hour clock. Again the asterisk (*) of hours, with or without steps, are also available e.g. 8,9-17/2 would schedule a task at 8 and then every 2 hours from 9am until 5pm.


Day of month allows specific days of the month, a comma separated list of days, an asterisk (*) for all, or a range of days with or without steps e.g. 1,5,7-31/2 for the 1st and 5th of the month followed by every second day until the end of the month.


The month number, again with the possibility of all, ranges and steps as above e.g. 1,3,5,6-9 schedules the job for January, March and May and then each month from June to September.


The day of the week looks odd, 0-7, that’s an eight day week surely? This is because all modern cron daemons understand the old assumption of 0-6 with 0 meaning Sunday and the more contemporary 1-7 with 7 being Sunday. Again we can specify (*) for all or a range without or without steps e.g. 0,2,5 (Sunday, Tuesday and Friday).


The command may be a single command, list or pipeline. The command can be scripted within the field. Commonly the command is the name of script. Do bear in mind that the PATH available at run time is fairly minimalist (the Vixie cron used on Ubuntu does allow equates within the crontab to specify the PATH), so it safer to specify the full path of your script.

Access to crontab is controlled in Vixie cron through /etc/cron.allow and /etc/cron.deny. In Dillon’s lightweight crontab access is expected to be controlled simply by requiring membership of the same group as that the crontab binary. I note however that in Slackware at least the default installation sets the binary group id to root but has the execute bit set for all users. If it desired to control access to cron jobs, as it may well be in a large scale academic environment, I would recommend that that a new group "cron" or "cronuser" is created and that the group id and execute permissions on the binary are modified accordingly. Membership of "cron" can then be allocated by seniority or upon request. Alternatively membership can be granted by default and then removed if the facility is being abused.

21.2. Exercises.

Read the crond and crontab manual pages.

Set up a cron job to check the disk usage on your host machine every every 15 minutes and email you if any file system is more than 60% full. Experiment with the parameters set in your script and for test purposes perhaps invert the alert so that you are emailed if any file system is less than 60% full.

Read the manual page for at and then set up an at job to check the CPU Osage in 10 minutes time and email you the results.

Set up a cron job that will run on the 2nd Monday of each month.

Setup a cron job to produce a report annually, starting in an hours time.

The layout and associated style sheets for this page are taken from the World Wide Web Consortium and used here under the W3C software licence.