1.16 Processes

A process is a running program. Each process on the system has a numeric process ID (PID). For a quick listing of the processes that you're running, just run the ps command on the command line. You should get a list like this:

  PID TTY STAT TIME COMMAND
  520  p0 S    0:00 -bash
  545   ? S    3:59 /usr/X11R6/bin/ctwm -W
  548   ? S    0:10 xclock -geometry -0-0
 2159  pd SW   0:00 /usr/bin/vi lib/addresses
31956  p3 R    0:00 ps

This is an abridged listing; yours will be much longer if you're running a windowing system. The fields are as follows:

PID The process ID.
TTY The terminal device where the process is running (don't worry about this for now).
STAT The process status; that is, what the process is doing at the given time and where its memory resides. For example, S means sleeping and R means running. Check the ps(1) manual page for all the symbols.
TIME The amount of CPU time (in minutes and seconds) that the process has used so far. In other words, this is the total amount of time that the process has spent running instructions on the processor.
COMMAND This one might seem obvious, but be aware that a process can change this field from its original value.

If you're interested in all processes on the system (not just the ones you're running), use ps ax, and if you'd like a more detailed report on process characteristics, use ps u. As with other programs, you can combine options, as in ps aux. Another important option that works in conjunction with a is w, which tells ps to print the full command name if it's too long to fit on one line.

To check on a specific process, add its PID to the argument list of the ps command. For example, one way to inspect the current shell process is with ps u $$ ($$ is a shell variable that evaluates to the current shell's PID).

You'll find information on two handy administration commands called top and lsof in Section 4.8. These can be useful when locating processes, even when doing something other than system maintenance.

1.16.1 Killing Processes

To terminate a process, send it a signal with the kill command. In most cases, all you need to do is this:

kill pid

There are many types of signals. The default signal is TERM, or terminate. You can send different signals by adding an extra option to kill. Let's say that you don't want to terminate the process, but rather, freeze it with the STOP signal. Use this command:

kill -STOP pid

A process stopped in this manner is still in memory, ready to pick up where it left off. Use the CONT signal to set the process on its way again:

kill -CONT pid

As you may recall from Section 1.2, CONTROL-C terminates a process running in the current terminal. This is the same as using kill to end the process with the INT (interrupt) signal.

The most brutal way to terminate a process is with the KILL signal. Other signals give the process a chance to clean up after itself, but KILL does not — the operating system terminates the process and forcibly removes it from memory. Use this as a last resort.

Warning?

Don't kill processes indiscriminately, especially if you don't know what they're doing. This can be akin to shooting yourself in the foot.

1.16.2 Job Control

Shells also support job control, a way to send STOP and CONT signals to programs by using funny keystrokes and commands. For example, you can send a STOP signal with CONTROL-Z and start the process again by typing fg or bg.

Despite the habits of many experienced users, job control is not necessary and can be confusing to beginners — it is not uncommon for the user to press CONTROL-Z instead of CONTROL-C and have many suspended processes sitting about.

If you want to run multiple shell programs, you can either run each program in a separate terminal window, put non-interactive processes in the background (explained in the next section), or learn to use the screen program.

1.16.3 Background Processes

Normally, when you run a Unix command from the shell, you do not get the shell prompt back until the program has finished executing. However, you can detach a process from the shell and put it in the "background" with the ampersand (&); this gives you the prompt back. For example, if you have a large file that you need to decompress with gunzip (you'll see this in Section 1.18), and you want to do some other stuff while it's running, run the command as in this gunzip example:

gunzip file.gz &

The shell responds by printing the PID of the new background process, and the prompt returns immediately so that you can continue working. The process also continues to run after you log out, which comes in particularly handy if you have a program that does a lot of number crunching that you need to run for a while. Depending on your setup, the shell may notify you when the process completes.

The dark side to background processes is that they may expect to work with the standard input (or worse). If the program wants to read something from the standard input when it is in the background, it can freeze (try fg to bring it back), or it may terminate. If the program writes to the standard output or standard error, the output can appear in the terminal window with no regard to anything else running there.

The best way to make sure that a background process doesn't bother you is to redirect its output (and possibly input) as described in Section 1.14.

If spurious output from background processes gets in your way, you should know how to redraw the content of your terminal window. bash and most full-screen interactive programs support CONTROL-L to redraw the entire screen. If a program is reading from the standard input, CONTROL-R usually redraws the current line. Unfortunately, pressing the wrong sequence in the wrong situation can leave you in an even worse situation than before. For example, CONTROL-R at the bash prompt puts you in an annoying mode called reverse isearch.