Conceptually, a process is best thought of as a standardized container into which any program can be read. When a program is started, a new container is created to hold the program as it executes. This container has standard parts such as attachments for standard input and standard output.

In reality, this is hogwash. A process is simply an entry in the kernel process table. The table refers to the process' pieces and parameters, including the program file of the program that is executing.

Each process is identified by a unique process id, which is a small integer. The pid is the index of the process' entry in the process table. When a new pid is needed, the next available pid with higher number is allocated. When the end of the process table is reached, the search begins again with the first entry.

Most processes are short-lived, and work alone. Sometimes, however, a set of processes work in concert to perform a task. Two situations that commonly result in such a set are

• starting multiple commands in a single pipeline so that standard output of one is connected to standard input of the next
• one process duplicating itself to manage a subtask. An example here is the sshd server, which duplicates itself (forks) to create another instance of itself to manage an incoming ssh connection.

Such a set of processes is called a process group. One process in each process group is the controlling process for the group. Called the process group leader, it can be used to suspend, kill or use a signal to affect, each process in the group.

Job Control

The shell uses process groups to manage tasks using shell job control. Each task that is started by the shell consisting of a single process or of a pipeline of processes forms a process group that is managed as a job. 

Normally, a shell user has a single job, running it until it completes. This job is called the foreground job. It is this job (process group) whose standard input is connected to the user input device. The shell sleeps until the foreground job exits, so you must wait until the foreground job is finished before you can start another command. This is the familiar way of executing shell commands on a Unix system.

Shell jobs may also be run in the background by appending & to the pipeline of commands. Background jobs execute in parallel with the shell.

Use of background jobs

Have you ever started a Unix command, realized that it was going to take a long time, and wanted to do something else in the meantime? What did you do? In this situation, the foreground job was tying up your terminal.

Most Unix users today do not know how to execute commands in the background. This is because most Unix jobs complete very fast. In addition, since background jobs by default send their standard output to the monitor (they actually inherit the attachment for standard output from their parent), running a background job that is producing output can make it impossible to do any meaningful work.

Some situations, however, find the use of the background helpful. One of these is the use of make to build software projects. Suppose you downloaded and extracted a new untility that must be compiled. The long step in this process involves the use of the make command. make triggers the utility's compilation, which generates a lot of status output that gets in the way of working on your terminal and that you may want to save for later examination. You can start make in the background, saving its stdout and stderr in a file such as make.out. In the example below, make is started in the background and a jobs command shows that it is the only job, with a job number of 1:

$ make > make.out 2>&1&
[1] 7657
$ jobs
[1]+  Running                 make > make.out 2>&1 &
$ 

Then you can continue your work using the shell. When the make finishes, the shell will notify you between commands:

[1]+  Done                    make > make.out 2>&1

Querying jobs

Shell jobs are assigned small job numbers for identification purposes. You can find out what these are using the jobs command, as indicated above. The job number can be used to control the job as detailed in the next section.

Do not get the job number, which is used only by the shell, confused with the process number, which is used by the system. In the example of job submittal above, the job number is 1 and the [single] process id is 7657.

Controlling jobs

There are three states for a shell job

• executing in the foreground. Since you can only provide input to one job at a time, there is at most one foreground job. If there is no foreground job, the shell is receiving input for more commands.
• executing in the background. Background jobs are independent. They execute in parallel with your shell process. 
• suspended.

You can use shell job control to move a job between these three states:

• to suspend the foreground job, use the keystroke that is mapped to susp. This is most commonly control-Z. You can enable this keystroke with the command (here, ^Z is typed shift-6 Z, rather than using the ctrl key.)

• to move a job that has either been suspended or is in the background to the foreground, use fg %N, where N is the job number
• to move a job that has been suspended to the background, use bg %N, where N is the job number.

Usually, %N can be omitted if it refers to the current job. For example, if you suspend the foreground job using ^Z, then type bg, the [formerly] foreground job will continue execution in the background.

Shell job control can be very useful if you start a task and do not have all the information you need for its input. In this situation, most users kill the job, find the information, then try again, OR they log in a second time. It can be much more efficient to 

1. suspend the current job using ^Z
2. find the information you want
3. continue the job using fg

You can use the shell to kill your jobs as well. If the job is the foreground job, ^C (or whatever character is mapped to the intr signal) is the same as typing ^C to each process in the job. You can kill jobs that are not in the foreground as well by use of kill %N.

Remember that shell jobs are merely process groups. You can control shell jobs at the process group level as well. We will cover this later.

Components of a Process

Some of the most important components of a process are