Scheduling Tasks

There are three ways to schedule commands in Fedora, all of which work in different ways. The first is the at command, which specifies a command to run at a specific time and date relative to today. The second is the batch command, which is actually a script that redirects you to the at command with some extra options set so that your command runs when the system is quiet. The last option is the cron daemon, which is the Linux way of executing tasks at a given time.

Using at and batch to Schedule Tasks for Later

If there is a time-intensive task you want to run, but you do not want to do it while you are still logged in, you can tell Fedora to run it later with the at command. To use at, you need to tell it the time at which you want to run and then press Enter. You then see a new prompt that starts with at>, and everything you type thereuntil you press Ctrl+Dcomprises the commands you want at to run.

When the designated time arrives, at performs each action individually and in order, which means later commands can rely on the results of earlier commands. In this next example, run at just after 5 p.m., at is used to download and extract the latest Linux kernel at a time when the network should be quiet:

[paul@caitlin ~]$ at now + 7 hours at> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2 at> tar xvfjp linux-2.6.10.tar.bz2 at> <EOT> job 2 at 2005-01-09 17:01

Specifying now + 7 hours as the time does what you would expect: at was run at 5 p.m., so the command runs just after midnight that night. When your job finishes, at sends you mail with a full log of your job's output; type mail at the console to bring up your mailbox and then press the relevant number to read at's mail.

If you have a more complex job, you can use the -f parameter to have at read its commands from a file, like this:

echo wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2\; tar xvfjp linux-2.6.10.tar.bz2 > myjob.job at -f myjob.job tomorrow

As you can see, at is flexible about the time format it takes; you can specify it in three ways:

• Using the now parameter, you can specify how many minutes, hours, days, or weeks relative to the current timefor example, now + 4 weeks would run the command one month from today.

• You can also specify several special times, including tomorrow, midnight, noon, or teatime (4 p.m.). If you do not specify a time with tomorrow, your job is set for precisely 24 hours from the current time.

• You can specify an exact date and time using HH:MM MM/DD/YY formatfor example, 16:40 22/12/05 for 4:40 p.m. on the 22nd of December 2005.

When your job is submitted, at reports the job number, date, and time that the job will be executed; the queue identifier; plus the job owner (you). It also captures all your environment variables and stores them along with the job so that, when your job runs, it can restore the variables, preserving your execution environment.

The job number and job queue identifier are both important. When you schedule a job using at, it is placed into queue a by default, which means it runs at your specified time and takes up a normal amount of resources.

There is an alternative command, batch, which is really just a shell script that calls at with a few extra options. These options (-q b -m now, if you were interested) set at to run on queue b (-q b), mailing the user on completion (-m), and running immediately (now). The queue part is what is important: Jobs scheduled on queue b are executed only when the system load falls below 0.8that is, when the system is not running at full load. Furthermore, they run with a lower niceness, meaning queue a jobs usually have a niceness of 2, whereas queue b jobs have a niceness of 4.

Because batch always specifies now as its time, you need not specify your own time; it simply runs as soon as the system is quiet. Having a default niceness of 4 means that batched commands get less system resources than queue jobs (at's default) and less system resources than most other programs. You can optionally specify other queues using at. Queue c runs at niceness 6, queue d runs at niceness 8, and so on. However, it is important to note that the system load is checked only before the command is run. If the load is lower than 0.8, your batch job is run. If the system load subsequently rises beyond 0.8, your batch job continues to run, albeit in the background, thanks to its niceness value.

When you submit a job for execution, you are also returned a job number. If you forget this or just want to see a list of other jobs you have scheduled to be run later, use the atq command with no parameters. If you run this as a normal user, it prints only your jobs; running it as a super-user prints everyone's jobs. The output is in the same format as when you submit a job, so you get the ID number, execution time, queue ID, and owner of each job.

If you want to delete a job, use the atrm command followed by the ID number of the job you want to delete. The next example shows atq and atrm being used to list jobs and delete one:

[paul@caitlin ~]$ atq 14      2005-01-20 23:33 a paul 16      2005-02-03 22:34 a paul 17      2005-01-25 22:34 a paul 15      2005-01-22 04:34 a paul 18      2005-01-22 01:35 b paul [paul@caitlin ~]$ atrm 16 [paul@caitlin ~]$ atq 14      2005-01-20 23:33 a paul 17      2005-01-25 22:34 a paul 15      2005-01-22 04:34 a paul 18      2005-01-22 01:35 b paul

In that example, job 16 is deleted using atrm, and so it does not show up in the second call to atq.

The default configuration for at and batch is to allow everyone to use it, which is not always the desired behavior. Access is controlled through two files: /etc/at.allow, and /etc/at.deny. By default, at.deny exists but is empty, which allows everyone to use at and batch. You can enter usernames into at.deny, one per line, to stop those users scheduling jobs.

Alternatively, you can use the at.allow file; this does not exist by default. If you have a blank at.allow file, no one except root is allowed to schedule jobs. As with at.deny, you can add usernames to at.allow one per line, and those users can schedule jobs. You should use either at.deny or at.allow: When someone tries to run at or batch, Fedora checks for her username in at.allow. If it is in there, or if at.allow does not exist, Fedora checks for her username in at.deny. If her username is in at.deny or at.deny does not exist, she is not allowed to schedule jobs.

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 on 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.allow file are. An empty cron.deny filethe defaultmeans everyone can set jobs. An empty cron.allow 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.allow 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/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly

The first four lines are optional: SHELL specifies which shell should be used to execute the job (defaults to the shell of the user who owns the crontab file, usually /bin/bash), PATH specifies the search path for executables to use, and you should avoid using environment variables there. MAILTO defines to whom mail should be sent. If this is not set, it uses the owner of the crontab, but if you do not want to receive mail when your job runs, just set it to "". Finally, HOME specifies the home directory of the user; again, this defaults to the user's home directory if left unspecified.

The next line, # run-parts, 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 (0-59), hour (0-23), day of the month (1-31), month of the year (1-12), and day of the week (0-7). 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 1, every hour of every day of every month and executes the command run-parts /etc/cron.hourly. The run-parts command is a simple script that runs all programs inside a given directoryin this case, /etc/cron.hourly. So, in this case, the job executes at 00:01 (1 minute past midnight), 01:01, 02:01, 03:01, and so on, and uses all the programs listed in the cron.hourly directory.

The next job runs at minute 2 and hour 4 of every day of every month, running runparts /etc/cron.daily. Because of the hour limitation, this script runs only once per day, at 4:02 a.m. Note that it uses minute 2 rather than minute 1 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.hourly, cron.daily, cron.weekly, and cron.monthly) is a collection of shell scripts that are run by run-parts. For example, in cron.daily are scripts such as rpm, which saves a list of your packages in /var/log/rpmpkgs every day; 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; that is, at 6:00:00, 6:01:00, and so on) to check for changes. However, any new jobs it finds are not executed until at least one minute has passed.

For example, if it is 6:01:49 (that is, 49 seconds past one 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 rereads its configuration files and sees the new job, but is not 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 the job makes no difference: cron runs 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 is not executed on subsequent days.

There are alternative ways of specifying dates. For example, you can use sets of dates and times by using hyphens or commas, such as hours 9-15 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 that you do not put spaces into these sets because the cron daemon would 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 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 is always 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) in which 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 (0-59), hour (0-23), day of the month (1-31), month of the year (1-12), day of the week (0-7), 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 ever morning at 6 a.m. so that we get a fresh start each morning. Here is how that would look in our crontab file:

0 6 * * * rm -rf /home/paul/sandbox/*

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

When 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 is 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.