Using at to Schedule Delayed Commands
• Introduction to at
• Scheduling Personal Reminders
• Scheduling Big Jobs for Later
• Using Batch to Manage Big Jobs
• Queue Levels in at
• Listing Your at Jobs
• Removing Your at Jobs
• Chronolgically Speaking—cron
• Manipulating Your crontab
• Decoding a crontab
• cron for the System Administrator
• Using cron to Schedule Administrative Tasks
• Summary

20 — Scheduling Processes

Typically, UNIX machines are left running all day and all night. UNIX offers several commands that let you take extra advantage of your existing computer resources. This chapter covers key concepts needed to schedule processes to run when you are not present to start them manually. This chapter introduces the at command, which is used to schedule a command to run once later, and the cron command, which is used to schedule commands that need to be run regularly. Using these two commands can help you manage your computer more effectively.

Using at to Schedule Delayed Commands

The at command is used to schedule a single command for execution at a later time. It is a tool that reads a series of commands from the standard input and schedules them for execution at a later time. Using at allows you to schedule system-intensive jobs for off hours.

Introduction to at

In its most basic form, you run at time and then type in a series of commands (followed by EOF) to be executed at the time you specify. The time can be one, two, or four digits (different versions of at support somewhat different time specifications; check your online manual by typing man at or check your hardcopy manuals to learn more about your version of at). If you use one or two digits, the time is in hours. If you use four digits, the time is in minutes. The time is in twenty-four hour clock time. The output of a job submitted to at is sent to you by electronic mail.

For example, to schedule a job to read the message of the day file and mail it to yourself at 5:30 p.m. today:

% # This example is from Solaris 2.3, which is SVR4

% at 1730

cat /etc/motd | mail myself

<ctrl><d>

warning: commands will be executed using /usr/bin/sh

job 763169400.a at Tue Mar  8 17:30:00 1994

%

Scheduling Personal Reminders

One important use of the at command is to schedule personal reminders. For example, if you have a meeting at 10:00 a.m. (and you run X11 and have the xmessage command), you might try the following command:

$ # This example is from HP-UX

$ at 10

xmessage -display \fIhostname\fB:0.0 "You have a meeting!!!"

<ctrl><d>

job 763056000.a at Mon Mar 07 10:00:00 1994

$

This command schedules an at job that will run the xmessage program at 10 a.m. to display the message "You have a meeting!!!" on your X display.

Scheduling Big Jobs for Later

Often, when you are using a computer, you will have large jobs that take up lots of computer time, memory, or do lots of input and output. You may want to run these jobs when you are away from your machine so that the machine won't be heavily loaded when you need it for other tasks.

For example, if you want to run a large make that compiles many C files to build a tool you are working on, you might try:

$ #This example is from a BSD system

$ cd make_directory

$ at 1930

at> make -k all > /dev/null

at> <ctrl><d>

$

Using Batch to Manage Big Jobs

The batch command is very similar to the at command, with some useful differences. Rather than specify a time for your job to execute, the batch command schedules it to run as soon as possible with the restriction that only one or two batch jobs run at a time. Jobs submitted with batch also run with a higher nice value so that they won't interfere with CPU usage. These two differences make batch a useful tool for scheduling large jobs that need to finish as soon as possible. The example of the make job shown previously is easily modified to work with batch:

$ #This example is from a Solaris system

$ cd make_directory;

$ batch

make -k all > /dev/null

<ctrl><d>

warning: commands will be executed using /usr/bin/sh

job 763072415.b at Mon Mar  7 14:33:35 1994

at: this job may not be executed at the proper time.

$

This job will run immediately and all error output will be mailed to you when it completes. Normal output is discarded.

Queue Levels in at

The at and batch commands as they have been introduced are two different interfaces to a single job-queuing system on SYSV-based UNIX (and other versions of UNIX that have added these features). The queuing system is implemented in the SYSV cron program (see "Chronologically Speaking—cron" later in this chapter). There are 25 queues available: a, b, and d-z ("c" is used internally to implement crontab). By default, there are two queues that are implemented. Queue "a" is used for jobs submitted by at; it allows a larger number of jobs (typically 4) to run with a small nice value (typically 1). Queue "b" is used for jobs submitted by batch; it allows a smaller number of jobs (typically 2) to run with a larger nice value (typically 2).

On systems that use this version of cron, you may be able to add new queue levels by editing the queuedefs file (typically in /usr/lib/cron/queuedefs).

The template for a queuedefs entry is:

q.[jobj][nicen][nwaitw]

in which:

q is the queue designation: "a", "b" or c-z




job is the maximum number of simultaneous jobs




nice is the nice value for each job




nwait is the number of seconds to wait between attempts to 
reschedule a job delayed because of njob limits

A typical queuedefs file looks like the following:

a.4j1n

b.2j2n90w

m.1j10n600w

Queue "a" can have a maximum of four jobs running with nice value of one and a (default) reschedule delay of sixty seconds. Queue "b" can have a maximum of two jobs running with nice value of two and a reschedule delay of ninety seconds. Queue "m" can have a maximum of one job running with nice value of ten and a reschedule delay of ten minutes.

Listing Your at Jobs

Both the SYSV and BSD versions of at allow you to examine the list of jobs you have in the queues. The method of getting the list and the appearance of the output are slightly different.

On SYSV, you can list at jobs using at -l, which lists all jobs that you have in any of the at queues. For example, with several batch jobs submitted and a couple of jobs waiting to run in queue "m" (as specified in the example in the preceding section, "Queue levels in at") and a single regular at job scheduled for 5:30 p.m., your output might look like the following:

$ date

Wed Mar  9 15:13:56 CST 1994

$ at -l

763247633.m     Wed Mar 09 15:13:53 1994

763255800.a     Wed Mar 09 17:30:00 1994

763247641.m     Wed Mar 09 15:14:01 1994

763247595.b     Wed Mar 09 15:13:15 1994

763247599.b     Wed Mar 09 15:13:19 1994

763247602.b     Wed Mar 09 15:13:22 1994

$

On BSD, you can list at jobs using atq, which lists all jobs that you have in the single queue. With a single job scheduled, your output might look like the following:

$ at

 LAST EXECUTION TIME: Mar 9, 1994 at 15:00

 Rank     Execution Date     Owner     Job #   Job Name

  1st   Mar 10, 1994 12:00   sartin    66588   stdin

$

Removing Your at Jobs

If you make a mistake or change your mind about running a job, you can remove it from the queue. If you didn't save the job ID that is printed by some versions of at when they add your job to the queue, you can get the job ID by listing at jobs and removing the job. On SYSV, you remove the job using at -r jobid:

$ at -l

763250700.a     Wed Mar  9 16:05:00 1994

$ at -r 763250700.a

$ at -l

$ 

On a BSD system, you remove the job using atrm jobid:

$ atq

 LAST EXECUTION TIME: Mar 9, 1994 at 15:00

 Rank     Execution Date     Owner     Job #   Job Name

  1st   Mar 10, 1994 12:00   sartin    66588   stdin

$ atrm 66588

 66588: removed

$ atq

no files in queue.

$ 

Chronolgically Speaking—cron

Although the at command is very useful for one-time jobs, it is somewhat difficult to use for scheduling repetitive tasks (see the note on using at to replace cron). UNIX also includes a program called cron that is responsible for running repetitively scheduled jobs in a flexible fashion.

Historically, cron was introduced as a tool for system administrators and originally only allowed scheduling of tasks by "root" using a file /etc/crontab that the cron program would read for information on what jobs to run at what times. Since that time, newer versions of cron have been introduced that allow individual users to have their own crontab, which specifies what jobs to run for that particular user.

Using at to Replace cron

On systems that don't have cron access for normal users, you can duplicate some of the features of cron by writing at jobs that reschedule themselves. For example, to write a script that runs weekly, you could add to the end of the script:

echo "sh this_script" | at 1900 thursday week

to reschedule this_script to run at 7 p.m. next Thursday. When this_script runs next Thursday, it will reschedule itself for the Thursday after that. Take great care when using scripts to reschedule themselves so that you don't lose control of your creations.

When cron runs a job for you, it executes using your user ID and privileges, but with a more sparse environment. A job executed by cron will run with sh (usually the Bourne shell) in your home directory, but will not execute .profile. The environment variables HOME, LOGNAME, PATH, and SHELL will be set. Your job should make minimal assumptions about its environment. For example, your PATH may only include /bin, /usr/bin and possibly your current working directory (which should be your home directory at the start of the job).

The output of each job you run is saved and sent to you by electronic mail.

Manipulating Your crontab

There are several different operations available from the crontab command that are used to view, modify, or remove your crontab. To see your current crontab, use crontab -l. This will list your current crontab on the standard output. For an example, see Listing 20.1.

To replace your crontab with a new crontab, use the command crontab new_crontab_file. This will replace your crontab completely, so make sure that new_crontab_file has any old crontab entries you want to keep. A good way to do this is to use crontab -l first:

$ crontab -l > new_crontab_file

$ vi new_crontab_file

[edit the file to update your crontab]

$ crontab new_crontab_file

$

Some versions of crontab support a special option for editing and replacing your crontab. If your system supports this, you can edit your crontab by executing crontab -e.

To make it so that cron will not execute any jobs for you, you could execute crontab /dev/null, which would give you an empty crontab. A better way to do this is to execute crontab -r, which will remove your crontab completely.

Decoding a crontab

A crontab has six fields:

minute (0-59)




hour (0-23)




day of month (1-31)




month of year (1-12)




day of week (0-6, 0 is Sunday)




Command (rest of line)

The first five fields are numeric patterns, which can be an asterisk (which means to use all legal values) or a list of elements. An element is either a single number or two numbers separated by a hyphen (which specifies an allowed range). Note that both a day of month and day of week are specified. If both fields are used, they are both honored. For example:

 0 17  1  *  0  date | mail user

will execute at 5 p.m. on the first of each month as well as at 5 p.m. on every Sunday.

Now look at Listing 20.1 in detail. Each line in the sample crontab illustrates a technique for using cron.

See LIST20_1 on the CD-ROM for a not-so-typical crontab.

Look at the line in Listing 20.1 that runs a program called hourly. Notice that both day fields, the month field, and the hour field are wild cards, whereas the minute field is "0." This means that the job will run on all days of all months at all hours at 0 minutes into the hour. This job runs every hour on the hour.

Look at line 2 in Listing 20.1 that runs a program called quarter_hourly. Note the change. Note the use of a list in the minute field. The minute field is now a list of "0,15,30,45." This means that the job will run on all days of all months at all hours at 0, 15, 30, and 45 minutes into the hour. This job runs every quarter hour.

The business_hourly script runs every hour during business hours. Note the use of ranges in the hour field (to limit the job to run between 8 a.m. and 6 p.m.) and the day of week field (to limit the job to run Monday through Friday).

Look at the line in Listing 20.1 that runs a program called daily. Notice that both day fields and the month field are wild cards, whereas the hour field is "8" and the minute field is "0." This means that the job will run every day at 8 a.m. The weekly script will run every Monday at 8 a.m. The monthly script will run just after midnight on the morning of the first of each month.

The two executions of the birthday script will each run once per year, one on April 20, with the argument rachel, and one on October 7, with the argument rob.

See Listing 20.2 for an example of a Korn shell script intended to be run as a cron job. This script sends a status summary based on the contents of two files in ~/status: a file named todo, which is a "to do" list, and a file named done, which is a list of tasks completed. During the week, you can move items from the todo file to the done. At the end of the week, this script can be run from cron and it will mail a weekly summary, add your done items to the file log, and mail a summary to you. Note that the script redirects all expected output either to a file or to the mail_command. Note that it tries to configure using only the environment variables LOGNAME and HOME. It uses only standard commands that are available in the default PATH.

Here is a cron entry to run this script every Monday morning at 8:00:

0     8     *     *     /u/sartin/bin/status_report

See LIST 20_2 on the CD-ROM for a sample cron script.

WARNING: Twice a year, users of cron get to experience the potential of having some jobs run twice or not at all when they were expected to run exactly once. The problem is that once a year (when you set your clocks back) some local clock times occur twice, and once a year (when you set your clocks ahead) some local clock times don't occur at all. Most versions of cron attempt to deal with this by making jobs that are scheduled for ambiguous times (those that occur twice in one day) run exactly once, and those that are scheduled for nonexistent times (the ones that were skipped when the clock was set ahead) run once, but at a different time than requested in the crontab. Historically, different versions of cron have run some jobs twice or not at all near the time change.

cron for the System Administrator

As a system administrator, you will either control cron and at access using cron.allow or cron.deny and at.allow and at.deny (Check your system's documentation to determine the locations of these files. They are typically in /usr/spool/cron or /var/spool/cron.) You will need to make a basic policy decision on whether users should be granted access to these tools. One possible policy is that all users are granted access and are denied access only if they abuse the facility; in this case, use the cron.deny file to list those users who should not use cron, and at.deny to list those who should not use at. Another possible policy is that users must request permission to use these tools; in this case, use cron.allow and at.allow to list users who have been granted permission.

Using cron to Schedule Administrative Tasks

You should use one or more crontabs to schedule all of your repetitive administrative tasks, such as backups, log file administration, news expiration, and file archival. See Listing 20.3 for a sample script that does simple log file pruning. Run this from your crontab as prunelog path_to_log_file .... It will keep the 10 most recent days (or weeks or hours) of log files available for review, and throw out older data to prevent running out of disk space.

If your system uses a cron like the SYSV one, you should take advantage of the user-specific crontabs to split administrative tasks. For example, all Usenet cron jobs should be in the crontab for user netnews (or whatever user ID you use for the news software). Only those jobs that need "root" privileges should be in the crontab for "root."

Here is a crontab entry that will execute this job to prune /usr/spool/mqueue/syslog:

0     1     *     *     *     /usr/adm/prunelog     /usr/spool/mqueue/syslog

See LIST20_3 on the CD-ROM for a program that prunes log delete files with cron.

Summary

In this chapter, you have learned how to use at to schedule one-time jobs; how to use batch (and at -q) to run large jobs without loading your system badly; and how to use cron to schedule recurring jobs. These techniques should help you to get maximum benefit out of your computer even when you are not around to use it.