Managing Processes
As introduced in Chapter 28, “Managing Daemons,” the Linux process model places significant importance on the ideas of process ownership and parent processes. Managing all the programs that run on a Linux system is a task that requires constant attention from the system administrator. The “mother of all processes” is called init, which is part of the kernel, and this process spawns all other processes, usually via the inittab file entries and the init scripts that define the system run levels.
Because Linux is a multiuser operating system, its processes also have other information attached to them. The user ID and the group ID, as well as a priority setting, are part of the process. You see, the process has all the rights of the user that started the process on the system. This is an important concept: the process is what prevents a user’s programs from overwriting another user’s home directory or reading his email. The process also makes it dangerous to run programs, especially unattended daemon programs, on the system as root because the program can read from and write to any file and all networks.
Rights, as specified by user and group IDs, are inherited by all processes spawned by any other process. For example, when a user logs on, the shell that is started to process the user commands, usually bash, has the same user ID as the user who has logged on, and so any process that the shell starts (such as ls, pine, and so on) has the same settings as well. When a process’s parent process finishes before the child process does, the child process is orphaned. In this case, init takes over as the parent process. If the user is no longer on the system and the process has not been flagged to continue running after the user logs off, using the command nohup (meaning “no hang-up,” or “don’t send the hang-up signal to the process when the user leaves”), init terminates the process.
Because every process must have a parent, and many programs use multiple processes to accomplish their tasks, child programs must have a way of passing some information back to their parents. Fundamental to this is the return code, a number that a program returns to the system after its completion. The problem is that the parent must be ready to accept the return code of the child process. In cases when this does not happen, the child process, although having completed processing, continues to exist in the system because its parent has not accepted the return value of the child process. Such a process is termed to be in a zombified state. Zombie processes don’t use many system resources, but an excess of them can cause problems and require intervention from the system administrator. The simplest way to clear up zombie processes is to kill their parent processes (that’s quite the social policy, if you ask me…). The children then become the property of init, which happily accepts the return code.
Using the /proc Directory Information
The /proc directory tree is a special directory structure that is a window on the running Linux kernel. This structure contains files and directories with all sorts of information that the kernel collects, and is useful for troubleshooting the system or learning about how it works. Utilities such as ps, top, and uptime gather information from this directory tree.
Some files in /proc are security sensitive—in particular, the file /proc/kcore is essentially a file pointing to all of the system’s memory, and as such can contain passwords or other information that others should not see. As a result, this file and any other files that contain sensitive information have the appropriate permissions set on them to prevent this sort of abuse. Table 32.1 covers a few files of interest in the /proc directory.
TABLE 32.1 A few files of interest in the /proc directory
File
Description
cpuinfo
Contains information about the processor(s) in the system, including the capabilities and bugs that Linux has detected. For example, many Intel processors contain the F0 0F bug that can cause the system to completely freeze when certain machine instructions are executed. Later kernels (2.0.33 and later, for example) can detect this and take appropriate measures to minimize the impact of these problems with the system processor. Other processor problems include the Pentium floating point math bug, but the kernel also accounts for differences in how floating point coprocessors and halt instructions are handled.
version
Contains the kernel version number, the system name, and the time and date that the kernel was compiled.
pci
Contains information about the devices on the system’s PCI bus, as well as the detected capabilities of the hardware that’s on the bus.
interrupts
Contains a count of all interrupts the system has processed, and the device that they are attached to.
The majority of these files are used by Linux developers to debug their systems, and this material, while interesting, is not vital to any administration task. The pci and interrupts files can provide insight into system problems, however.
Viewing the System Load Average
The load on a system in the UNIX world is measured by using a number called the load average. This number is based on the number of processes waiting to run at a given time.
The best command for viewing the system load average is uptime. The output of this command also reveals how long the system has been up, along with the load average over the last 1, 5, and 15 minutes, and number of users logged on. If you’d rather gather all this information yourself, it’s in /proc/loadavg—the first three numbers are the load average.