Any Processes in the House?

Any Processes in the House?

The basic program you use to find out which processes are around is ps (for process status). Although the details of ps (wait! — how did you know?) vary somewhat from one version of UNIX to another, two main kinds of ps exist: the System V kind and the BSD kind. (SVR4 uses the System V kind of ps, even though SVR4 has a great deal of BSD mixed in. Linux uses a ps that looks more or less like BSD.)

Mind your ps (and qs)

If you run plain ps, no matter which version of UNIX you have, you get a list of the processes running from your terminal (or window, if you’re using X Windows). The list looks something like this:

PID   TTY     TIME COMMAND
24812 ttyp0   0:01 -csh
25973 ttyp0   0:00 ps

The PID column gives the process identification, or process ID. To help keep processes straight, UNIX assigns every process a unique number as an identifier. The numbers start at 1 and go up. When the PIDs become inconveniently large (about 30,000 or so), UNIX starts over again at 1 and skips numbers that are still in use. To get rid of a stuck process, you have to know its PID to tell the system which process to destroy.

The TTY column lists the terminal from which the process was started. In this case, ttyp0 is the terminal, which happens to be pseudoterminal number 0. (Because UNIX systems are written by and for nerds, they tend to start counting at 0 rather than at 1.) UNIX uses a pseudoterminal when you’re logged in from a window on your screen or from a remote system through a network rather than through a real, actual, drop-it-on-your-foot-and-it-hurts terminal. For our purposes, all terminals act the same, whether they’re real, pseudo, or whatever.

The TIME column is the amount of time the computer has spent running this program. (The time spent waiting for you to type something or waiting for disks and printers and so forth doesn’t count.)

The COMMAND column shows, more or less, the name of the command that started the process. If the process is the first one for a particular terminal or pseudoterminal, the command name starts with a hyphen.

The Linux ps

�Linux��The Linux ps command has one additional column:

PID  TTY STAT  TIME COMMAND
1797 pp5 S     0:00 -bash
1855 pp5 R     0:00 ps

The STAT column shows the status of the process. According to the man page (online documentation) for the command, R means runnable, S means sleeping, D means uninterruptible sleep, T means stopped or traced, and Z means a zombie process. Wow! For our purposes, R means that it’s a command you ran, and the other stuff doesn’t matter much.

Fancier ps (and qs)

The System V version of ps has lots of options, most of which are useless. One of the more useful is -f, which produces a "full" listing:

UID   PID   PPID   C    STIME TTY      TIME COMMAND
johnl 11764  3812  0 14:06:02 ttyp3    0:00 /usr/bin/emacs
johnl 11766 11764  0 14:06:05 ttyp3    0:00 /bin/sh -i
johnl 11769 11766 10 14:06:15 ttyp3    0:00 ps -f
johnl  3812  3804  0  Jan 18  ttyp3    0:04 -sh

(We did it from a different window, which you can tell because the PID of the shell is different.)

This listing has a few more columns than does the basic ps listing, and a few columns are different. The UID column is the username — just what it looks like. PPID is the parent PID, the PID of the process that started this one. We had run emacs from the shell and then told emacs to start another shell to run a ps command.

The parent PIDs reflect the order in which the processes started each other: The login shell process (number 3812) is the parent of emacs, which in turn is the parent of the shell /bin/sh, which is the parent of ps. (We could explain why the processes aren’t listed in order, but — trust us — you don’t want to know.) All processes in a UNIX system are arranged in a genealogical hierarchy based on which process started which. The grand ancestor of them all is process number 1, which is named init. You can trace the ancestry of any process back to init. "Hark! I am yclept Ps, son of Bourne Shell, daughter of Emacs, son of Dash-shell (or is that Dashiell?), great-great-grandson of the ancient and holy Init!"

The C column is a totally technoid number relating to how much the process has been running lately. Ignore it. STIME is the start time, the time of day the process began. If it began more than 24 hours ago, this column shows the date. TTY is the name of the terminal the process is using. If you run a GUI, such as X Windows, and you run the xterm program in a window (as we did in this example), the entry for TTY doesn’t show the terminal you are using. Instead, it lists the pseudoterminal assigned to the window (a useless piece of information). Sometimes the TTY column shows a ?, which means that the process is a daemon that doesn’t use a terminal.

The COMMAND column shows the full command that began this process, including (in some cases) the full pathname of the program. (Because standard system programs live in the directories /bin and /usr/bin, you see them frequently in ps listings.)

If you’re logged in on several terminals or in several windows, you may want to see all your processes, not just the ones for the current terminal. With the System V version of ps, you can ask to see all processes for a given user by using this command:

ps -u tracy

This command lists all processes belonging to user tracy. You can ask to �see any user’s processes, not just your own. You can get a full listing for that user, too:

ps -fu tracy

System V has other, less useful switches for ps, notably -e, which shows every process in the entire system.

Berkeley ps (and qs)

The basic report from the BSD version of ps looks like this example:

 PID TT STAT  TIME COMMAND
7335 p4 S     0:00  -csh (csh)
7374 p4 R     0:00 ps

The PID, TIME, and COMMAND columns are the same as those you already know about. (In the COMMAND column, the true name of the program is listed in parentheses if a dash or something is in the regular name.) The TT column lists a short form of the terminal name (pseudoterminal 4, in this case). STAT lists the status of the process: R means that the process is running right now; anything else means that it isn’t. Usually, you don’t care unless you have a stuck process and you wonder whether it’s sitting there waiting for you to type something (then its status is I or IW) or running off into the woods (then its status is R).

Adding the -u switch gives a user-oriented report, although perhaps they had a different kind of user than you and we in mind, as you may gather from this example:

USER       PID %CPU %MEM   SZ  RSS TT STAT START  TIME COMMAND
johnl     7375 0.0   0.9  196  436 p4 R    14:59  0:00 ps -u
johnl     7335 0.0   0.6  196  316 p4 S    14:56  0:00 -tcsh (tcsh)

The %CPU and %MEM columns list the percentage of the available central processor time and system memory the process has taken recently (these numbers are usually close to 0). RSS is Resident Set Size, a measure of how much memory the process is using right now, measured in thousands of bytes (abbreviated as K). The ps command, for example, takes 436K bytes (which is horrifying when you consider that the entire UNIX system used to fit into 64K total bytes). The START column lists the time of day the process began.

You can ask for a particular terminal’s process list by using the -t option, as shown in this example:

ps -tp4

With the -t option, you have to use the same two-letter terminal abbreviation ps uses. Have fun guessing it. Try the two-letter abbreviations that appear in the TT column of the ps listing.

The BSD version of ps has lots of other useless options, including -l for a long technoid listing; -a for all processes, not just yours; and -x to show processes not using a terminal. You have no way to ask for all processes belonging to a particular user.

To see all the processes you started, type this incantation:

ps -aux | grep tracy

Replace Tracy’s name with your own username. This line redirects the output of the ps command to the grep command (described in Chapter 8), which throws away all the lines except those that contain your username.

�Technical Stuff�� Why cd isn’t a process

People always ask us (well, someone asked once) why the cd command doesn’t always act the way they expect it to. The problem is what is called in erudite circles Lamarckian Heritability and what we call "you look like your mother."

When a parent process creates a child process, the child inherits many characteristics from its parent, such as the username, terminal, and (this one is important) current directory. The child, ungrateful for its heritage — as all children are — can change many of these things. Because inheritance goes only one way, changes in the child don’t affect the parent. Suppose that you create a new process (type sh to start a new shell as the second process). Then go to some directory other than the one you are using, such as /tmp, by typing cd /tmp. Then type pwd to make sure that you are in /tmp. Leave the new shell by typing exit, and then type pwd back in the old shell to prove that you’re back in the original directory.

This example proves that cd can’t be a normal command executed in its own process. If it were, the new directory would apply to only that process. As soon as the process was finished, you would be back in the shell with the directory unchanged.

The authors of the various shells finessed this problem using what’s technically known as a kludge (something that works but that you’re not proud of; it rhymes with “huge,” not with “fudge.”) The kludge checks especially for the cd command and handles it itself in the shell. The exit and logout commands also are handled in the shell for the same reason.

Here’s an example of where you may run into this stuff: If you make a shell script (see Chapter 12) that contains a cd command, the cd affects only subsequent commands in that script. After your shell script finishes running, you find yourself back in the original directory as though the cd never occurred. Although you can write a script that does change the directory, doing so is so complicated that even wizards shrink from the task.