The Process Chain to Your Window (Unix Power Tools, 3rd Edition)

24.20. The Process Chain to Your Window

Almost everything we cover in this book works as well from an old-style, full-screen terminal as it does from an terminal window (like xterm) under the X Window System (Section 1.22). Actually, a lot of it works on an old printing teletype, too! In all of those cases, you're interacting with a Unix shell. This article covers things you should know about using a shell from an X window. We'll talk specifically about the X11R6 xterm client, but this generally applies to any window with a shell inside of it -- like GNOME terminal. This is a guided tour, so it helps to be at a workstation or other X display. If you can't take the tour, please scan through and look for the points I make along the way.

If you don't have an xterm window open, open one (by clicking on an icon, choosing a menu entry, or however you usually do it). We'll call this the "first window." Find its tty (Section 2.7). Next, in this first window, set an environment variable (Section 35.3) with a unique name and any value you want. You might call it FAVCOLOR and set the value to purple. Then, in that same window, type cd /tmp to change your current directory to /tmp. Finally, type xterm -rv -sb (with no & after its name); this should open a second xterm window. Here's what that first xterm should look like (we'll show C shell syntax here):

% tty
/dev/pts/1
% setenv FAVCOLOR purple
% cd /tmp
% xterm -rv -sb
   (cursor sits here; there's no shell prompt)

When your new second xterm pops open, it should be in reverse video (swapped foreground/background colors, the -rv option) to make it easy to identify, with a scrollbar too. In it, type tty to get its tty number, which will be different from the previous xterm's. Run env or printenv (Section 35.3), and you should see the special environment variable (like FAVCOLOR) that you set. Type pwd; the current directory should be /tmp.[77]

[77]If your setup files assume you're in your home directory (Section 3.7), you may have some problems.

If you've managed to follow this twisty series of steps, you've started a chain of processes (Section 24.3).

You can see that chain of processes by typing the command ps aux or ps -ef (Section 24.5). You should get lines something like these:

% tty
/dev/pts/3
% ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
jpeek      675     1  0 May13 ?        00:00:14 xterm
jpeek      681   675  0 May13 pts/1    00:00:00 zsh
jpeek    14850   681  0 15:58 pts/1    00:00:00 xterm -rv -sb
jpeek    14852 14850  0 15:58 pts/3    00:00:00 zsh
jpeek    14992 14852  0 16:07 pts/3    00:00:00 ps -ef

This is the chain of processes that led to the second window. Let's start from the bottom and work up. From the ps -ef command,[78] you'll see that the ps command itself had PID (process ID) 14992; its parent's PID (PPID) was 14852. So the process that started the ps process is the shell running in that window: in my case, a Z shell, zsh, with PID 14852. Notice that both of these processes are running on the same tty (Section 2.7) named pts/3. That's a way to find all the processes in a particular window: check the tty name. This zsh is the shell running in this particular xterm. When you exit the shell (by typing CTRL-d or exit), the window will close too -- but don't try that yet! Instead, find the parent of the shell; it's the xterm process, which is running on -- are you surprised? -- another tty, pts/1. This makes sense, because you started xterm from another window, the first window. There's a shell running in the first window too; it's the zsh with PID 681. The parent of the first window's shell is, yes, another xterm, PID 675. And its parent has PID 1; this is init (Section 24.2), the "grandparent" of all processes on your system.

[78]Note that, if your system's process ID numbers have "recycled" and started over from 1, the ps command may not have the highest number.

Your window system may not work quite this way. The parent of the top-level xterm might not be init. Also, an xterm could be owned by root instead of by you. Still, you should have a "chain" of processes, something like the one I described, on your system.

Why did we go through all this? One reason is so you'll know how to track the processes that lead to an xterm -- and to know what to look for if you have to kill (Section 24.12) a hung window or a process in a window. It's also to show that the environment from a parent window (here, the first window) -- the current directory, environment variables, and so on -- is passed to the child window (here, the second window). Finally, it's to show what happens when you close a window by exiting the shell: the shell terminates, so its parent xterm process terminates too.

So what happens to a shell running in a window if you close the window by clicking the "X" box on the window frame or by choosing the close or destroy commands in the window manager? The xterm gets a signal (Section 24.10), and the system hopes that it dies. But it may not die, and the process may stay around. Instead of trusting the window manager to kill a window and the processes in it, I tend to use ps so I know for sure that all the processes are gone. Knowing the stuff we've looked at here lets me identify a window and its processes.

But let's not kill things! Instead, in the second window, type exit at the prompt. The window should go away. And, in the first window, you should have a new prompt. (If you had started the second xterm in the background (Section 23.2), you could have kept working in the first window while the second window ran, too. But watch out for the zsh and ksh options named bg_nice and bgnice, respectively, which run background commands at lower priority. You probably don't want your new windows to run at low priority, so be sure that option isn't set.)

-- JP


24.19. Why You Can't Kill a Zombie		24.21. Terminal Windows Without Shells