Managing System Processes

Thus far, you haven't had to worry much about which processes were running and what they were called. At most, you've used the jobs command to manage a list of jobs started from a single shell's command line.

Sometimes, however, you need to list and modify running processes on a systemwide basis. Using the command line, you can list all the running processes on a system, kill processes by their process ID number, or reprioritize processes relative to other processes in the system so that you can control processor time allocation on a busy system.

Because normal users can list all processes but have access to modify only their own processes, management of systemwide processes is often done as the root user so that all processes can be managed and/or modified.

Listing Running Processes

The ps command lists processes that are currently running. Because a given Linux system might have a very long list of running processes, and because so much data can be displayed about the properties and resources of each process, the ps command supports a wide range and variety of options to modify its behavior.

The simplest way to call ps is without arguments. Whether called by root or by a normal user, calling the command this way has the effect of listing all the processes owned by the current login with information in several columns:

 [you@workstation20 ~]$ ps   PID TTY        TIME CMD  971  pts/0  00:00:00 bash  1028 pts/0  00:00:00 ps [you@workstation20 ~]$ 

This basic ps listing is very small because it includes only those processes owned by the user who has called ps and that were started from the command line. This listing indicates that only two processes have been started by you at the command line: the bash program (the login shell, which provides the command line) and the ps program, which lists itself because it is running, actively displaying the list of processes owned by the user. There are several columns of information in the ps output:

• The PID column displays the systemwide process ID number. When you learn to kill or reprioritize processes in the following sections, you use this number in referring to specific processes.

• The TTY column displays the system terminal from which the process was started.

• The TIME column displays the amount of real time that has been actively used by the process since its start. For many processes, these numbers are very small because processes like the shell are typically asleep much of the time waiting for user input, rather than actively calculating or working.

• The CMD column displays the command entered to start the process, possibly including (depending on the options supplied to ps) options or arguments supplied by the user on the command line.

The basic ps listing can be helpful when you're logged in as a normal user and simply want to manage your own processes. However, from a system administration perspective, it is often important to get information about all processes currently running on a Linux system or to get extended information about the processes being listed. This way, you can monitor the behavior of multiple users or server processes as the system functions on a day-to-day basis.

By supplying options or arguments to the ps command, you can change the types of processes that are listed and the information that is displayed about each process. The most common and useful ps options are shown in Table 28.1.

Table 28.1. Common Options Used to Alter the Behavior of the ps Command

Option	Description
x	Do not limit process listing to those processes launched from a terminal; include, for example, processes started from a menu or taskbar icon.
v	List memory use information in the output
a	Display processes launched from a terminal owned by all users, not just by the user issuing the ps command.
-e	List all processesthose owned by any user on the system, whether or not they are launched from a terminal.
-f	Do a full listing of information, including process owner, process parent ID, and start time, among other things.
-U user	List only processes owned by the user whose login ID is user.
-G group	List only processes owned by the members who belong to the group known as group.
-H	Use indentation and sorting to show process parent and child relationships visually in the ps output.

You can mix and match the ps options listed in Table 28.1 on the command line with relative impunity.

Perhaps the two most common ways to call the ps command are with the -e and -f options or with the a and x options, in the following formats:

 ps -ef ps ax 

Both of these commands have similar effects: They display a listing of processes owned by all users, including those processes not launched from a controlling terminal. These two options enable the root user (or any other user, for that matter) to get a quick listing of all running processes on the system.

Where to Learn More

The ps command is quite powerful and flexible, and it's capable of accepting numerous options and displaying a great deal of information about running processes. The ps command is far too involved to explore fully in this chapter. For more information on using ps, consult the ps manual page. For more information on reading manual pages, refer to Chapter 18, "Becoming Familiar with Shell Environments."

A more complete printed reference for ps can be found in Sams Teach Yourself Unix System Administration in 24 Hours.

Adjusting Process Priority

The root user can adjust the priority of any running process upward (less CPU time) or downward (more CPU time) using the renice command and the process ID number of the related process. This way, the administrator can ensure that critical processes on an overloaded system get as much CPU time as possible, sometimes at the expense of other processes. To use the renice command, call it as follows:

 renice priority pid 

Replace priority with the desired priority, from -20 (highest priority) to +19 (lowest priority). Replace pid with the process ID number of the process whose priority you want to change. For example, to maximize the priority of process number 664 while minimizing the priority of process 702, you enter the following:

 [root@workstation20 you]# renice -20 664 664: old priority 0, new priority -20 [root@workstation20 you]# renice [phone]: old priority 0, new priority 19 [root@workstation20 you]# 

You can see the effects of renice operations in the output of the ps command as well because of the appearance of N (decreased priority) or < (increased priority) in the STAT column, as follows:

  PID TTY  STAT TIME COMMAND [...]  664 ?    S<   0:00 /usr/sbin/sshd  678 ?    S    0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid  702 ?    SN   0:00 sendmail: accepting connections  712 ?    S    0:00 sendmail: Queue runner@01:00:00 for /var/spool/client [...] 

This fragment shows process 664 with a status of S<, which indicates a sleeping process with increased priority relative to other processes. Process 702, on the other hand, shows a status of SN, indicating a sleeping process with decreased priority relative to other processes.

Only the root user can adjust process priority downward (increased priority). Normal users can adjust the priorities of their own processes upward (decreased priority) if they choose.

Killing Running Processes

Sometimes you need to forcefully kill a running processfor example, if a buggy piece of software has stopped responding, or if a single process has for some reason "run away" and is using vast amounts of CPU time, thus robbing the system of productivity potential.

To kill a running process, use the kill command followed by the process ID number of the process you want to kill. For example, to kill process 702, enter the following:

 [root@workstation20 you]# kill 702 [root@workstation20 you]# 

This command sends a signal to process 702 that termination has been requested. Process 702 closes any open files and attempts to exit gracefully. From time to time, you find that even after trying to kill a process, it remains in the process list. Processes that can't be removed with a normal kill must then be terminated with the -KILL argument:

 [root@workstation20 you]# kill -KILL 702 [root@workstation20 you]# 

Because the -KILL argument is fairly destructiveit doesn't give a process any chance to close open files or network connections, but rather closes them forcefully as isyou should use it only when other termination attempts fail.

Other Signals and Another Way to Kill

From time to time, you might also see references to the commands kill -9 and kill -HUP.

The kill -9 command is equivalent to kill -KILL and works because signal number 9 is the number used by the system itself to identify the SIGKILL signal.

The kill -HUP command sends the SIGHUP or "hangup" signal to a process. In theory, this signal is supposed to cause a process to restart itself (often to cause recently edited configuration files to be reread). Many server and root-level processes understand this signal, but many user-level processes (for example, a gedit or an emacs process) either ignore it or treat it like a normal terminate request. The -HUP signal is thus best used only when you are very familiar with a process or when the documentation for a particular program suggests it.

Another command, the killall command, is sometimes used to kill all processes of a given name, as in the following example:

 killall emacs 

The killall command can certainly be convenient, but use of this command is not recommended, especially on busy systems. Experience over decades of Unix use has demonstrated that it is too easy on a busy system to miskey or to misread the output of ps and then, using killall, to kill in one single step any number of important processes that shouldn't have been killed!

As you expect, the root user is able to terminate or kill any process in the system by process ID, and normal users are able to terminate or kill only processes that they own.