Some readers of my December 2002 Linux Magazine column, Using Power Wisely, probably
haven't seen what I call a process
tree. So I've made four quick-and-dirty sketches to go along
with the article. Here they are -- with snippets of the article to help
you put them in context. This page also touches on another important
Linux feature: job control.
It's important to understand how a Linux process is started and what information it carries. When one process starts ("forks") another, the new child process typically inherits its parent's UID. (The UID is the user ID number, which is how the Linux kernel keeps track of which user "owns" the process). So, the new process has the privileges of the user who started it.
Let's look at an example:
Figure One shows a snapshot of the tree of processes running in a terminal window. Notice that each process has a unique ID number (PID); in this case, all have the same UID. Each parent process is waiting for its child process to finish. To start the first process, the user clicked a button; the window manager invoked the xterm program. xterm then starts a child shell process (this user's shell is zsh) in its window. The shell prints a prompt and waits for you to type a command, like this:
zsh% vim myprogIf that command isn't part of the shell (which vim isn't), the shell starts a child process and waits for it to finish, which is what Figure One is showing. When you quit vim, the shell sees that its child process has finished, so you get another prompt. There you can run another command -- or type exit, which tells the shell to terminate. When xterm sees that its child zsh process has terminated, it closes the window and terminates too.
Figure One -- Process tree: a program in an xterm window
Modern Unix-type systems have a powerful process management feature called job control. Among other things, job control lets you stop a process; the parent shell will print another prompt, where you can start another process. To stop a process running in a terminal, press Ctrl-Z.
So, if the user running vim wanted to view a file using less, he doesn't have to open another terminal window or quit vim; instead, from vim's command mode, he can press Ctrl-Z to get a shell prompt, then start less:
zsh% vim myprogFigure Two shows the process tree while vim is stopped and less is running.
+ Stopped vim myprog
zsh% less somefile
After quitting less (so its process terminates), the user can type fg ("foreground") at a prompt to tell the shell to re-start the vim process. Then the process tree looks like Figure One again. At this point, the vim process is exactly where it was when it stopped: the same option settings, the cursor is on the same character in the same line, and so on. The process state is preserved. As you can tell, this is a handy feature! (And there's much more to job control. See a good Linux reference.)
Figure Two -- Process tree: stopped program, running program
and the process tree looks like Figure Three. Notice that both su and its child shell (here, root uses bash) have the UID 0.Figure Three -- Process tree: user's shell, root shell
If you use root access often, though, it's nice to be able to keep the root shell handy -- with its command history, current directory, and everything just as you left them. You can use job control to stop a shell: use the command suspend. For example, to suspend the bash shell and the su process that started it:
...You're back to the original shell, which is running as UID 1234. The process tree looks like Figure Four. The child su process is waiting; you can't type commands to it until you type fg to bring it to the foreground. So, until you do, commands you start will run with the UID 1234.
+ Stopped su
Figure Four -- Stopped root shell
Contact Jerry Peek