Processes

The term process was first used by the designers of the Multics operating system, an ancestor of the UNIX operating system. Process has been given many definitions. In this chapter, we use the intuitive definition that makes process equivalent to task, as in multiprocessing or multitasking. In a simple sense, a process is a program in execution. However, because a program can create new processes (e.g., the shell spawns new shells), for a given program, there may be one or more processes in execution.

At the lowest level, a process is created by a fork system call. (A system call is a routine that causes the kernel to provide some service for a program.) A fork creates a separate, but almost identical running process. The process that makes the fork system call is called the parent process; the process that is created by the fork is called the child process. The two processes have the same environment, the same signal-handling settings, the same group and user IDs, and the same scheduler class and priority but different process ID numbers. The only way to increase the number of processes running on a UNIX system is with the fork system call. When you run programs that spawn new processes, they do so by using the fork system call.

The way you think about working on a UNIX system is tied to the concepts of the file system and of processes. When you deal with files in UNIX, you have a strong “locational” feeling. When you are in certain places in the file system, you use pwd (present working directory) to see where you are, and you move around the file system when you execute a cd (change directory) command.

A special metaphor applies to processes in UNIX. The processes have life: they are alive or dead; they are spawned (born) or die; they become zombies or they become orphaned. They are parents or children, and when you want to get rid of one, you kill it.

On early PCs, only one program at a time could be run, and the user had exclusive use of the machine. On a time-sharing system like UNIX, users have the illusion of exclusive use of the machine even though dozens or hundreds of others may be using it simultaneously The UNIX kernel manages all the processes executing on the machine by controlling the creation, operation, communication, and termination of processes. It handles sharing of computer resources by scheduling the fractions of a second when the CPU is executing a process, and by suspending and rescheduling a process when its CPU time allotment is completed.

There are two categories of processes running on a UNIX system, foreground and background. A foreground process is one that is run by executing a command at the command line, such as the ps command in the following section. When running a foreground process, the command is executed immediately The system will devote whatever resources are necessary to complete the process, and-when the process is completed-the shell prompt will appear, indicating that the process is complete. A background process is one where the process is scheduled for execution at a later time when resources are available, according to priorities set by the system administrator.

The ps Command

To see what is happening on your UNIX system, use the ps (process status) command. The ps command lists all of the active processes running on the machine. If you use ps without any options, information is printed about the processes associated with your terminal. For example, the output from ps shows the process ID (PID), the terminal ID (TTY), the amount of CPU time in minutes and seconds that the command has consumed, and the name of the command, as shown here:

 $ ps   PID    TTY        TIME    COMD  3211    term/41    0:05    ksh 12326    term/41    0:01    ps 12233    term/41    0:20    ksh  9046    term/41    0:02    vi

This user has four processes attached to terminal ID term/41; there are two Korn shells (ksh), a vi editing session, and the ps command itself.

Process ID numbers are assigned sequentially as processes are created. Process 0 is a system process that is created when a UNIX system is first turned on, and process 1 is the init process from which all others are spawned. Other process IDs start at 2 and proceed with each new process labeled with the next available number. When the maximum process ID number is reached, numbering begins again, with any process ID number still in use being skipped. The maximum ID number can vary, but it is usually set to 32767.

Because process ID numbers are assigned in this way, they are often used to create relatively unique names for temporary user files. The shell variable $$ contains the process ID number of that shell, and $$ refers to the value of that variable. If you create a file temp$$, the shell appends the process ID to temp. Because every current process has a unique ID, your shell is the only one currently running that could create this filename. A different shell running the same script would have a different PID and would create a different filename. For example,

 #touch temp$$

would create a temp file with the currently running process ID appended. If the current PID happened to be 3464, the created file would be named temp3464.

When you start up or boot a UNIX system, the UNIX kernel (/unix) is loaded into memory and executed. The kernel initializes its hardware interfaces and its internal data structures and creates a system process, process 0, known as the swapper. Process 0 forks and creates the first user-level process, process 1.

Process 1 is known as the init process because it is responsible for setting up, or initializing, all subsequent processes on the system. It is responsible for setting up the system in single-user or multiuser mode, for managing communication lines, and for spawning login shells for the users. Process 1 exists for as long as the system is running, and it is the ancestor of all other processes on the system.

How to Kill a Process

You may want to stop a process while it is running. For instance, you may be running a program that contains an endless loop, so that the process you created will never stop. Or you may decide not to complete a process you started, either because it is hogging system resources or because it is doing something unintended. If your process is actively running, just hit the BREAK or DELETE key However, you cannot terminate a background process or one attached to a different terminal this way, unless you bring it back to the foreground.

You should observe some cautions when using kill to end processes. Before you attempt to kill a process, you should ensure that you have correctly identified the process ID (PID) you wish to kill. In this “family” relationship that is built as processes spawn others, you can inadvertently kill a process that is the parent of the one you want to kill, and leave an orphan, or-in the worst case-a zombie (a process that still appears in the process table as though it were active, but either has been killed or has completed and is consuming no resources).

You may also transpose numbers in the PID and kill a process that is being used for a different purpose, even a system-level process. The results can be disastrous, especially if you use what is known as a “sure (or unconditional) kill.” This type of kill is discussed in the next section.

To terminate such a process, or kill it, use the kill command, giving the process ID as an argument. For instance, to kill the process with PID 2312 (as revealed by ps), type

 $  kill  2312

This command sends a signal to the process. In particular, when used with no arguments, the kill command sends the signal 15 to the process. (Over 30 different signals can be sent on UNIX systems. See Table 11–1, in the section “Signals and Semaphores,” for a list.) Signal 15 is the software termination signal (SIGTERM) that is used to stop processes.

Table 11–1: The Thirty Most Common UNIX Signals

Signal	Abbreviation	Meaning
1)	HUP	Hangup
2)	INT	Interrupt
3)	QUIT	Quit
4)	ILL	Illegal instruction
5)	TRAP	Trace/breakpoint trap
6)	ABRT	Abort
7)	EMT	Emulation trap
8)	FPE	Floating point exception
9)	KILL	Kill
10)	BUS	Bus error
11)	SEGV	Segmentation fault
12)	SIGSYS	Bad system call
13)	PIPE	Broken pipe
14)	ALRM	Alarm clock
15)	TERM	Terminated
16)	USR1	User signal 1
17)	USR2	User signal 2
18)	CLD	Child status changed
19)	PWR	Power failure
20)	WINCH	Window size change
21)	URG	Urgent socket condition
22)	POLL	Pollable event
23)	STOP	Stopped
24)	STP	Stopped (user)
25)	CONT	Continued
26)	TTIN	Stopped terminal input
27)	TTOU	Stopped terminal output
28)	VTALRM	Virtual timer expired
29)	PROF	Profiling timer expired
30)	XCPU	CPU time exceeded

Some processes, such as the shell, do not die when they receive this signal. You can kill processes that ignore signal 15 by supplying the kill command with the −9 flag. This sends the signal 9, which is the unconditional kill signal, to the process. For instance, to kill a shell process with PID 517, type

 $ kill −9 517

You may want to use kill −9 to terminate sessions. For instance, you may have forgotten to log off at work. When you log in remotely from home and use the ps command, you will see that you are logged in from two terminals. You can kill the session you have at work by using the kill −9 command.

To do this, first issue the ps command to see your running processes:

 $ ps  PID     TTY        TIME    COMD  3211    term/41    0:05    ksh 12326    term/41    0:01    ps 12233    term/15    0:20    ksh

You can see that there are two kshs running: one attached to terminal 41, one, to terminal 15. The ps command just issued is also associated with terminal 41. Thus, the ksh associated with term/15, with process number (PID) 12233, is the login at work. To kill that login shell, use the command

 $  kill  −9  12233

You can also kill all the processes that you created during your current terminal login session. A process group is a set of related processes, for example, all those with a common ancestor that is a login shell. Use the command

 $  kill  0

to terminate all processes in the process group.

If you program in Shell (see Chapter 20), you may want to know if a particular process is running prior to executing a command. The −0 (zero) option of kill allows you to do this. Putting the string

 kill  −0  pid

into your shell script will return a value indicating whether or not the indicated process (pid) is alive.

Parent and Child Processes

When you type a command line on your UNIX system, the shell handles its execution. If the command is a built-in command known by the shell (echo, break, exit, test, and so forth), it is executed internally without creating a new process. If the command is not a built-in, the shell treats it as an executable file. The current shell uses the system call fork and creates a child process, which executes the command. The parent process, the shell, waits until the child either completes execution or dies, and then it returns to read the next command.

Normally when the shell creates the child process, it executes a wait system call. This suspends operation of the parent shell until it receives a signal from the kernel indicating the death of a child. At that point, the parent process wakes up and looks for a new command.

When you issue a command that takes a long time to run (e.g., a troff command to format a long article), you usually need to wait until the command terminates. When the troff job finishes, a signal is sent to the parent shell, and the shell begins paying attention to your input once again. You can run multiple processes at the same time by putting jobs into the background. If you end a command line with the ampersand (&) symbol, you tell the shell to run this command in the background. The command string

 $ cat * troff -mm lp 2> /dev/null &

causes all the files in the current directory to be formatted and sent to the printer. Because this command would take several minutes to run, it is placed in the background with the & symbol.

When the shell sees the & at the end of the command, it forks off a child shell to execute the command, but it does not execute the wait system call. Instead of suspending operation until the child dies, the parent shell resumes processing commands immediately If anything goes wrong with the process, the output of the lp command is redirected to the device /dev/ null (discarded) to avoid a lengthy printout of garbage.

The shell provides programming control of the commands and shell scripts you execute. The command format

 $ (command; command; command) &

instructs the shell to create a child or subshell to run the sequence of commands, and to place this subshell in the background.