UNIX System Administration Handbook - Evi Nemeth [37]
4 Controlling Processes
A process is the abstraction used by UNIX to represent a running program. It’s the object through which a program’s use of memory, processor time, and I/O resources can be managed and monitored.
It is part of the UNIX philosophy that as much work as possible be done within the context of processes, rather than handled specially by the kernel. Although portions of the kernel cannot be made to fit this model, it is used by most system software. System and user processes all follow the same rules, so you can use a single set of tools to control them both.
4.1 COMPONENTS OF A PROCESS
A process consists of an address space and a set of data structures within the kernel. The address space is a set of memory pages1 that the kernel has marked for the process’s use. It contains the code and libraries that the process is executing, the process’s variables, its stacks, and various extra information needed by the kernel while the process is running. Because UNIX supports virtual memory, there is not necessarily a correlation between a page’s location within an address space and its location inside the machine’s physical memory or swap space.
The kernel’s internal data structures record various pieces of information about each process. Some of the more important of these are:
• The process’s address space map
• The current status of the process (sleeping, stopped, runnable, etc.)
• The execution priority of the process
• Information about the resources the process has used (for accounting)
• The process’s signal mask (a record of which signals are blocked)
• The owner of the process
In traditional UNIX, a process also keeps track of which instructions the CPU is currently executing on its behalf. Some modern systems allow more than one “processor” to execute code within a process at the same time (the extra processors may be real or simulated, depending on the hardware and system load). In these systems, information about each execution context is contained in an object called a thread.
In concept, two threads can be scheduled and prioritized independently despite being contained within a single process. In practice, the thread API used by most vendors doesn’t encourage such fine-grained scheduling. Most scheduling issues are still handled at the process level, and thus far, multithreading has had little impact on system administration.
Many of the parameters associated with a process directly affect its execution: the amount of processor time it gets, the files it can access, and so on. In the following sections, we discuss the meaning and significance of the parameters that are most interesting from a system administrator’s point of view. These attributes are common to all versions of UNIX.
PID: process ID number
The kernel assigns a unique ID number to every process. Most commands and system calls that manipulate processes require you to specify a PID to identify the target of the operation. PIDs are assigned in order as processes are created. When the kernel runs out of PIDs, it starts again at 1, skipping over any PIDs that are still in use.
PPID: parent PID
UNIX does not supply a system call that creates a new process running a particular program. Instead, an existing process must clone itself to create a new process. The clone can then exchange the program it is running for a different one.
When a process is cloned, the original process is referred to as the parent, and the copy is called the child. The PPID attribute of a process is the PID of the parent from which it was cloned.2
UID and EUID: real and effective user ID
A process’s UID is the user identification number of the person who created it, or more accurately, it is a copy of the EUID value of the parent process. Usually, only the creator (aka the “owner”) and the superuser are permitted to manipulate a process.
See page 79 for more information about UIDs.
The EUID is the