Fedora™ Unleashed, 2008 edition

 PID TTY       TIME CMD
4242 pts/0 00:00:00 su
4245 pts/0 00:00:00 bash
4286 pts/0 00:00:00 consolehelper-g
4287 pts/0 00:00:00 userhelper
4290 pts/0 00:00:00 system-config-d
4291 pts/0 00:00:00 python2
4293 pts/0 00:00:00 ps

Note that not all output from the display is shown here. But as you can see, the output includes the process ID, abbreviated as PID, along with other information, such as the name of the running program. As with any UNIX command, many options are available; the proc man page has a full list. A most useful option is aux, which provides a much more detailed and helpful list of all the processes. You should also know that ps works not by polling memory, but through the interrogation of the Linux /proc or process file system. (ps is one of the interfaces mentioned at the beginning of this section.)

The /proc directory contains quite a few files — some of which include constantly updated hardware information (such as battery power levels and so on). Linux administrators often pipe the output of ps through a member of the grep family of commands to display information about a specific program, perhaps like this:

$ ps aux | grep system-config-display
root 4286 0.0 0.3 13056 3172 pts/0 S 11:57 0:00 system-config-display

This example returns the owner (the user who launched the program) and the PID, along with other information, such as the percentage of CPU and memory use, size of the command (code, data, and stack), time (or date) the command was launched, and name of the command. Processes can also be queried by PID, as follows:

$ ps 4286
4286 pts/0 S 0:00 system-config-display

You can use the PID to stop a running process by using the shell's built-in kill command. This command asks the kernel to stop a running process and reclaim system memory. For example, to stop the system-config-display client in the example, use the kill command like this:

$ kill 4286

After you press Enter (or perhaps press Enter again), the shell might report the following:

[1]+ Terminated system-config-display

Note that users can kill only their own processes, but root can kill them all. Controlling any other running process requires root permission, which should be used judiciously (especially when forcing a kill by using the -9 option); by inadvertently killing the wrong process through a typo in the command, you could bring down an active system.

Using the kill Command to Control Processes

The kill command is a basic UNIX system command. You can communicate with a running process by entering a command into its interface, such as when you type into a text editor. But some processes (usually system processes rather than application processes) run without such an interface, and you need a way to communicate with them, too, so we use a system of signals. The kill system accomplishes that by sending a signal to a process, and you can use it to communicate with any process. The general format of the kill command is as follows:

# kill option PID

A number of signal options can be sent as words or numbers, but most are of interest only to programmers. One of the most common is this:

# kill PID

This tells the process with PID to stop; you supply the actual PID.

# kill -9 PID

is the signal for kill (9 is the number of the SIGKILL signal); use this combination when the plain kill shown previously does not work.

# kill -SIGHUP PID

is the signal to 'hang up' — stop — and then clean up all associated processes as well. (Its number is -1.)

As you become proficient at process control and job control, you will learn the utility of a number of kill options. You can find a full list of signal options in the signal man page.

Using Priority Scheduling and Control

No process can make use of the system's resources (CPU, memory, disk access, and so on) as it pleases. After all, the kernel's primary function is to manage the system resources equitably. It does this by assigning a priority to each process so that some processes get better access to system resources and some processes might have to wait longer until their turn arrives. Priority scheduling can be an important tool in managing a system supporting critical applications or in a situation in which CPU and RAM use must be reserved or allocated for a specific task. Two legacy applications included with Fedora include the nice and renice commands. (nice is part of the GNU sh-utils package, whereas renice is inherited from BSD UNIX.)

The nice command is used with its -n option, along with an argument in the range of -20 to 19, in order from highest to lowest priority (the lower the number, the higher the priority). For example, to run the gkrellm client with a low priority, use the nice command like this:

$ nice -n 12 gkrellm &

The nice command is typically used for disk- or CPU-intensive tasks that might be obtrusive or cause system slowdown. The renice command can be used to reset the priority of running processes or control the priority and scheduling of all processes owned by a user. Regular users can only numerically increase process priorities (that is, make tasks less important) with this command, but the root operator can use the full nice range of scheduling (-20 to 19).

System administrators can also use the time command to get an idea of how much time and what proportion of a system's resources are required for a task, such as a shell script. (Here, time is used to measure the duration of elapsed time; the command that deals with civil and sidereal time is the date command.) This command is used with the name of another command (or script) as an argument like this:

# time -p find / -name core -print
/dev/core
/proc/sys/net/core
real 1.20
user 0.14
sys  0.71

Output of the command displays the time from start to finish, along with the user and system time required. Other factors you can query include memory, CPU use, and file system input/output (I/O)