Using cron to Run Jobs Repeatedly

The at and batch commands work well if you just want to execute a single task at a later date, but they are less useful if you want to run a task frequently. Instead, there is the crond daemon for running tasks repeatedly based upon systemand userrequests. Cron has a similar permissions system to at: Users listed in the cron.deny file are not allowed to use Cron, and users listed in the cron.aiiow file are. An empty cron.deny filethe defaultmeans everyone can set jobs. An empty cron.aiiow file means that no one (except root) can set jobs.

There are two types of jobs: system jobs and user jobs. Only root can edit system jobs, whereas any user whose name appears in cron.aiiow or does not appear in cron.deny can run user jobs. System jobs are controlled through the /etc/crontab file, which by default looks like this:

SHELL=/bin/sh

PATH=/usr/iocai/sbin:/usr/iocai/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command

SHELL=/bin/sh

PATH=/usr/iocai/sbin:/usr/iocai/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command

17

*

*

*

*

root

run-

parts —report /etc/cron,

houriy

25

6

*

*

*

root

test

-x /usr/sbin/anacron ||

run-parts

--report

/etc/cron.

.daiiy

47

6

*

*

7

root

test

-x /usr/sbin/anacron ||

run-parts

--report

/etc/cron.

.weekiy

52

6

1

*

*

root

test

-x /usr/sbin/anacron ||

run-parts

--report

/etc/cron.

.monthiy

The first two lines specify which shell should be used to execute the job (defaults to the shell of the user who owns the crontab file, usually /bin/bash), and the search path for executables that will be used. It's important that you avoid using environment variables in this path statement, as they may not be set when the job runs.

The next line starts with a pound sign (#) and so is treated as a comment and ignored. The next four lines are the important parts: They are the jobs themselves.

Each job is specified in seven fields that define the time to run, owner, and command. The first five commands specify the execution time in quite a quirky order: minute (059), hour (023), day of the month (131), month of the year (112), and day of the week (07). For day of the week, both 0 and 7 are Sunday, which means that 1 is Monday, 3 is Wednesday, and so on. If you want to specify "all values" (that is, every minute, every hour, every day, and so on), use an asterisk, *.

The next field specifies the username of the owner of the job. When a job is executed, it uses the username specified here. The last field is the command to execute.

So, the first job runs at minute 17, every hour of every day of every month and executes the command run-parts /etc/cron.houriy. The run-parts command is a simple script that runs all programs inside a given directoryin this case, /etc/cron.houriy. So, in this case, the job will execute at 00:17 (17 minutes past midnight), 01:17, 02:17, 03:17, and so on, and will use all the programs listed in the cron.houriy directory.

The next job runs at minute 25 and hour 6 of every day of every month, running runparts /etc/cron.daiiy. Because of the hour limitation, this script will run only once per day, at 6:25 a.m. Note that it uses minute 25 rather than minute 17 so that daily jobs do not clash with hourly jobs. You should be able to guess what the next two jobs do, simply by looking at the commands they run!

Inside each of those four directories (cron.houriy, cron.daiiy, cron.weekiy, and cron.monthiy) are a collection of shell scripts that will be run by run-parts. For example, in cron.daiiy you will have scripts like logrotate, which handles backing up of log files, and makewhatis, which updates the whatis database. You can add other system tasks to these directories if you want to, but you should be careful to ensure your scripts are correct.

Caution

The cron daemon reads all the system crontab files and all user crontab files once a minute (on the minute, i.e. at 6:00:00, 6:01:00, and so on) to check for changes. However, any new jobs it finds will not be executed until at least 1 minute has passed.

For example, if it is 6:01:49 (that is, 49 seconds past 1 minute past 6 a.m.) and you set a cron job to run at 6:02, it will not execute. At 6:02, the cron daemon will reread its configuration files and see the new job, but it will not be able to execute it. If you set the job to run at 6:02 a.m. every day, it will be executed the following morning and every subsequent morning.

This same situation exists when deleting jobs. If it is 6:01:49 and you have a job scheduled to run at 6:02, deleting it will make no difference: cron will run it before it rereads the crontab files for changes. However, after it has reread the crontab file and noticed the job is no longer there, it will not be executed in subsequent days.

There are alternative ways of specifying dates. For example, you can use sets of dates and times by using hyphens of commas, such as hours 915 would execute at 9, 10, 11, 12, 13, 14, and 15 (from 9 a.m. to 3 p.m.), whereas 9,11,13,15 would miss out at the even hours. Note that it is important you do not put spaces into these sets because the cron daemon will interpret them as the next field. You can define a step value with a slash (/) to show time division: */4 for hours means "every four hours all day", and 0-12/3 means "every three hours from midnight to noon." You can also specify day and month names rather than numbers, using three-character abbreviations: Sun, Mon, Tue, Fri, Sat for days, or Jan, Feb, Mar, Oct, Nov, Dec for months.

As well as system jobs, there are also user jobs for those users who have the correct permissions. User jobs are stored in the /var/spool/cron directory, with each user having his own file in his named after his usernamefor instance, /var/spool/cron/paul or /var/spool/cron/root. The contents of these files contain the jobs the user wants to run and take roughly the same format as the /etc/crontab file, with the exception that the owner of the job should not be specified because it will always be the same as the filename.

To edit your own crontab file, type crontab e. This brings up a text editor (vim by default, but you can set the editor environment variable to change that) where you can enter your entries. The format of this file is a little different from the format for the main crontab because this time there is no need to specify the owner of the jobit is always you.

So, this time each line is made up of six fields: minute (059), hour (023), day of the month (131), month of the year (112), day of the week (07), and then the command to run. If you are using vim and are new to it, press i to enter insert mode to edit your text; then press Esc to exit insert mode. To save and quit, type a colon followed by wq and press Enter.

When programming, we tend to use a sandbox subdirectory in our home directory where we keep all sorts of temporary files that we were just playing around with. We can use a personal job to empty that directory every morning at 6 a.m. so that we get a fresh start each morning. Here is how that would like in our crontab file:

If you are not allowed to schedule jobs, you will be stopped from editing your crontab file.

Once your jobs are placed, you can use the command crontab l to list your jobs. This just prints the contents of your crontab file, so its output will be the same as the line you just entered.

If you want to remove just one job, the easiest thing to do is type crontab e to edit your crontab file in vim; then, after having moved the cursor to the job you want to delete, type dd (two ds) to delete that line. If you want to delete all your jobs, you can use crontab r to delete your crontab file.

4 PREV

Was this article helpful?

0 0

Post a comment