Unix Background Control Using the shell job control commands
From "Migration",  Access to Wang, February 1994
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Background processing forms one of the important means that system administrators are able to perform lengthy processes. Without the capability of running programs without intervention it is doubtful commercial data processing operations would be able to continue for long.

The Wang VS provides fairly good facilities for background processing, including a hierarchical queueing system, the ability to run jobs using the environment of a user, and job priorities. It does not provide a means of launching jobs a specific times, but a multitude of third-party providers have seen to this need. The VS is also missing a means for easy scheduling of ad hoc requests, such as one-time jobs for end users.

Unix systems provide solutions to most production background processing needs. Unix provides not one but three or more methods for scheduling jobs in background. These approaches include the means of running more than one job from a workstation, submit a job for later execution, or setting up a job to be run at specific intervals.

A caution: many of the features mentioned below are implemented differently in various Unix versions and some may not be present at all. I will mention some of these differences where they are known, but check your system's manual pages for more information.

Command-line job control

The simplest form of background processing in Unix systems is that handled by the shell itself. First pioneered at Berkeley with the C shell (/bin/csh), shell job control commands are also available in the Korn shell (/bin/ksh), the Bourne-Again shell (/bin/bash), and other shells. The syntax for all of these shells is similar so the following examples should work in any environment.

(Note that job control commands are not available with the Bourne shell (/bin/sh), the default shell for most Unix systems. If your system does not include any of the above shells public- domain versions of all three can be found through the Internet or user groups. The Korn shell is the best choice for most uses, since its syntax is nearly identical to the Bourne shell.)

To use command line job control you must meet the following qualifications:

• Use a shell capable of job control (see above).

• Have access to the command prompt.

• Have monitor functions set on (a system administration function; more on this later).

• Have execute access to the commands to be run.

• Once these requirements are met, shell job control is very simple: virtually any command that can be entered on the command line can be sent into background by adding an ampersand (&) on the end of the line. Consider this workstation interchange:

$ find / -name core > /home/dsb/core.list & [1] 1703

In this example the find command is used to locate all files named "core" and create a list named core.list in directory /home/dsb. The ampersand at the end of the line tells the command interpreter to create a new background task for the job; the system returns the job number and process ID. The job number is a means of tracking background jobs tied to this user's session, while the process ID is the unique identifier assigned by the system for any task. After displaying this information, the command prompt returns and another command may be entered.

The newly-created task is released from the foreground and continues in its own process. Screen output from these background jobs continues to your foreground session, though, which can be somewhat distracting. For this reason it's best to release only jobs that do not echo any information to the screen while operating or send any output to a file. Another alternative is to execute the job within the nohup (no hangup) environment, which directs all screen I/O to a file (by default, nohup.out). Naturally, a job that stops for user input will not work in either of these circumstances, unlike later versions of the VS which allow missing information to be entered from the operator's console.

There are several commands for managing shell background jobs. To check the status of background jobs, enter jobs and press enter; the system will display all of the background jobs by their job numbers, showing the commands entered and their current status (running, stopped, terminated, etc.). Entering jobs -p will also show the process IDs for these jobs. The fg and bg commands pull jobs back into foreground and place them in background, respectively. In the preceding example, entering fg %1 pulls background job 1 into foreground; if it is still executing, your prompt will disappear, replaced by the blank line of an executing job. To place this or any other executing job into background, hit control-Z (^Z, CTRL plus Z) then enter the bg command. (Be careful not to hit control-Z more than once; in many Unix systems it also serves as a means of logging off the system!)

It's important to note that jobs created from the shell are still tied to your prompt. If you attempt to log off after creating such tasks, the system will report any jobs still running; if you still choose to exit, these jobs will be terminated. (The nohup option described above will allow the job to continue even after you log off.)

Running jobs at later times

The shell job control commands are useful, but they release their tasks immediately. It is often necessary to schedule big jobs for more appropriate times, such as after hours. Most Unix systems provide the at and batch commands to allow commands to be run at a later time. Like its name implies, the at command allows jobs to be run at the time you select. The syntax for indicating time is remarkably close to English; Examples of the use of the at command include:

Command	Result
at 0800 tomorrow cmd	Start at 8:00 tomorrow
at 8 now + 1 day cmd	Same as above
at 8pm Feb 23 cmd	Run on specific day
at 5am next Tuesday cmd	Run next Tuesday

The jobs submitted through at can be viewed by entering at -l. Jobs can be removed with at -r.

AT&T-based Unix systems also offer the batch command. The batch command is similar to at except that it does not allow a time to be entered; instead, commands submitted through batch are held until system resource levels allow them to be run. The resource threshold for batch commands to run is set by the system administrator in the queuedefs file, which also sets default priorities and other scheduling information for at, cron, and other background schedulers.