System components
2.5 Processes and job control
On a multitasking computer, all work on a running program is performed by an abstraction called a process. This is a collection of resources such as file handles, allocated memory, program code and CPU registers that is associ-ated with a specific running program. A cursory overview of various operat-ing system models for runnoperat-ing programs follows. On modern operatoperat-ing sys-tems, processes can contain many concurrent threads which share program resources.
2.5.1 The Unix process model
Unix starts new processes by copying old ones. Users start processes from a shell command line interface program or by clicking on icons in a window manager.
Every Unix process has a process ID (PID) which can be used to refer to it, suspend it or kill it entirely.
A background process is started from a shell using the special character & at the end of the command line.
find / -name ’*lib*’ -print >& output &
The final & at the end of this line means that the job will be run in the background.
Note that this will not be confused with the redirection operator >& since it must be the last non-whitespace character of the command. The command above looks for any files in the system containing the string ‘lib’ and writes the list of files to a file called ‘output’.
If we want to see what processes are running, we can use the ps com-mand. ps without any arguments lists your current processes, i.e. all processes owned by the user identity you logged in with that are connected to the shell you are currently using. ps takes many options, for instance ps auxg will list all user processes in detail on BSD-like systems, while ps -efl will pro-vide a similar, if not entirely compatible, listing on System V-like systems.
Some Unix-like systems support both the BSD and System V flags to the ps command.
Processes can be stopped and started, or killed once and for all. The kill command does this and more. In fact, it sends generalized signals to running processes, not only the kill signal. There are two versions of the kill command.
One of them is built into the C-shell and the other is not. If you use the C-shell then you will never care about the difference unless the process table is full. We shall nonetheless mention the special features of the C-shell built-ins below. The kill command takes a number called a signal as an argument and another number
called the process identifier or PID for short. Kill send signals to processes. Some of these are fatal and some are for information only. The two commands
kill -15 127 kill 127
are identical. They both send signal 15 to PID 127. This is the normal termination signal and it is often enough to stop any process from running.
Programs can choose to ignore certain signals by trapping signals with a special handler. One signal they cannot ignore is signal 9.
kill -9 127
is a sure way of killing PID 127. Even though the process dies, it may not be removed from the kernel’s process table if it has a parent (see next section).
2.5.2 Child processes and zombies
When we start a process, the new process becomes a child of the original. If one of the children starts a new process then it will be a child of the child (a grandchild).
Processes therefore form hierarchies. Several children can have a common parent.
All Unix user-processes are children of the initial process init, with process ID 1.
If we kill a parent, then (unless the child has detached itself from the parent) all of its children die too. If a child dies, the parent is not affected. Sometimes when a child is killed, it does not die but becomes defunct or a zombie process. This means that the child has a parent which is waiting for it to finish. If the parent has not yet been informed that the child has died, because it has been suspended itself for instance, then the dead child is not completely removed from the kernel’s process table. When the parent wakes up and receives the message that the child has terminated (and its exit status), the process entry for the dead child can be removed.
Most Unix processes go through a zombie state, but most terminate so quickly that they cannot be seen. A few hang around and use up valuable process slots, which can be a problem. It is not possible to kill a zombie process, since it is already dead. The only way to remove a zombie is to either reactivate the process which is waiting for it, or to kill that process. Persistent zombie processes are usually caused by software bugs.
2.5.3 The Windows process model
Like Unix, processes under Windows/NT can live in the foreground or in the background, though unlike Unix, Windows does not fork processes by replicating existing ones. A background process can be started with
start /B
In order to kill the process it is necessary to purchase the Resource kit which contains a kill command. A background process detaches itself from a login session and can continue to run even when the user is logged out.
Generally speaking, Windows and Novell abhor processes. Threads are the preferred method for multitasking. This means that additional functionality is often implemented as modules to existing software, rather than as independent objects.
The shutdown of the whole system is normally performed from the Windows menu. Any logged on user can shut down a host. Background processes die when this happens and updates from an administrator could fail to be applied.
A number of shutdown commands also exists for shutting down local or remote systems; some of these are commercial third-party software.
2.5.4 Environment variables
Environment variables are text-string variables which can be set in any process [294]. Normally they are set by users in shell environments in order to commu-nicate user preferences or configuration information to software. In the C-shell, they are set with the command
setenv VARIABLE value
and are not to be confused with C-shell’s local (non-inherited) variables which are created with set variable=value. In the original Bourne shell they are set by VARIABLE=value
export VARIABLE
The export command is needed to make the variable global, i.e. to make it inheritable by child processes. In newer Bourne shells like ksh and bash, one can simply write
export VARIABLE=value
The values of these variables are later referred to using the dollar symbol:
echo $VARIABLE
When a process spawns a child process, the child inherits the environment variables of its parent. Environment variables are an important way of transmitting preference information between processes.
On Windows systems environment variables are set in the DOS prompt inter-face by
set VARIABLE=value
Try not to confuse this with the C-shell’s set command. Environment variables in Windows are later dereferenced using the percent prefix and suffix:
echo %%VARIABLE%%