A Process Smorgasbord (Cooking with Linux)

15

Mar

A Process Smorgasbord (Cooking with Linux)

Submitted by Marcel Gagne

by Marcel Gagné

This article first appeared in the December 2002 Linux Journal

François, vite! Our guests will be here any moment. Quoi? You say that you have already prepared everything? Excellent, François! I see that you have already brought up a healthy supply of the 1998 Barossa Valley Shiraz. It will pair nicely with tonight's menu, don't you think? Qu'avez-vous dit? Ah, the theme of this issue . . . it is System Administration, mon ami, and tonight I have decided to look into process management. But of course, François, even something as basic as processes can be the center of exciting dishes, non?

What did you say, François? Ah, our guests are here! Welcome, mes amis, to Chez Marcel, home of fine Linux cooking, tantalizing atmosphere, and incredible wine, non? Your tables and the wine are ready. Please sit and my faithful waiter will fill your glasses. I must tell you that François is being unusually efficient tonight. I don't know what has gotten into him. One less thing to manage, non?

As everyone in this restaurant knows, everything that is running on your Linux machine is a process; every shell, every open connection to the Internet, every game, everything. In some cases, programs will spawn multiple processes of their own. These are child processes. Technically, every process is a child process of some parent except one -- that is "init", the master process, non? Children can spawn more children and they can spawn more. You can use "ps" to list them all, but in time, monitoring all this procreation can be quite exhausting. Mon Dieu, mes amis, I think I need a sip of my wine right now.

To obtain a quick and dirty view (so to speak) of what process is the child of what other process, you can type the "pstree" command. Note the first few lines of output below and init's position.

While this looks neat, it is somewhat lacking in information. You can get the same effect (but with more information) by using your old friend, the "ps" command. The "f" flag displays a forest view through which you can see the process trees. A little joke, mes amis. Ahem, note that in the following output the lines tend to be a little long. Each line starts with my username (marcel).

Transforming the sea of processes into something that readily catches the eye is exactly what George MacDonald had in mind when he created TreePS. This program is an interactive, graphical process monitor with an on-the-fly color-coded display, thereby making it easier to nail down individual tasks. This one is certainly worth the download, mes amis. Get the source at the following, friendly URL.

To build Treeps, extract the source (with a "tar -xzvf treeps-1.2.1.tar.gz", then run the "./Setup" script from the installation directory. After the pre-build configuration takes place, you'll be told to do a "make install". You then run the program by typing "treeps &".

Figure 1 : Process Nirvana, courtesy of Treeps" (Click the image for a full size view.)

The initial view is that of your own processes as launched from init and that is where the fun starts. Moving your mouse pointer over a process displays some basic information, the equivalent of what you would get from a "ps x". Right-click and a pop-up menu will give you the option of renicing the process, viewing its man page, and more.

From the button bar up top, click on the various selections. Aside from a view of your own processes, you can choose to see the daemon processes or simply everything. If you click the information button (the one with an "i" on it) your mouse pointer will change to an "i" as well. Click on any process and an information window will appear detailing more about the running process than you might have thought was there. From that window, you can drill down even further. Click the "File/Dir" button and you'll see every file open by that process. For the truly curious, the "Mem maps" button displays where in memory every chunk of code resides.

The features are numerous to say the least but the color-coding is what really caught my eye. While the program is running, turn on the "color map viewer" by clicking on the color-bar button. By cycling through the various options, you can highlight processes based on user ID, group ID, total CPU time, current CPU load, process status (sleeping, running, zombie, etc), resident memory, image size, and more.

Under the "Program" menu, there's another little treat in store for you. It is called "System Info" and brings up the System Information App Launcher. From this button-laden window, you can quickly view tons of information about your system from your routing table to loaded modules, kernel level, pci devices, uptime, disk partitions, runlevels, and more.

Viewing things from a different perspective can give you a new appreciation for even the familiar. Indeed, it can be a mind expanding experience, non? As whimsical as the next item on our menu appears to be, I found it a lot of fun to watch and work with. Whether it makes a great process monitor or not, will depend on your feelings towards lava lamps. Written by John Heidemann, lavaps was inspired by the idea of calm computing from "The Coming Age of Calm Technology" by Mark Weiser and John Seely Brown.

Figure 2 : Mind-expanding process management, lava lamp style."

The idea is that processes are represented as fluid blobs in a lava lamp. The larger the blob, the greater its memory usage. The faster it moves, the greater its CPU usage. Like any decent process monitor, it allows for identification of processes, renicing, and killing. Start by visiting the lavaps website and picking up a copy of the package. Meanwhile, François will serve the double-butter brie.

For the RedHat users out there, pre-packaged RPMs are available. For the others, never fear -- building lavaps is simply another example of the famous (dare I say "classic") extract and build five step.

To start your lava lamp, type "lavaps &". What you'll see is a small lava lamp appear on your desktop. Right-click and a menu will pop up offering you a number of options. The proc menu will tell you the process ID and the name of the process. It also allows you to send various signals (kill) to the process from forceful termination to temporary suspension.

Running lavaps to monitor and administer processes certainly sets an otherworldly kind of mood. The one thing I did not like is that the default lamp was actually fairly small on my 1024x768 display. Overriding this requires that you set X resources. This is easily done by modifying the "$HOME/.lavapsrc configuration file. In mine, the only thing I changed was the geometry. Here's what my .lavapsrc file looks like.

lavaps.geometry: 204x404+700+0

Speaking of otherworldly, mes amis, the strangest excursion into the secret life of your processes is probably highlighted by an unusual game of Doom, the classic 3D shooter from ID Software. Back in 1997, ID Software released the source code to Doom and many ports followed. One of them was XDoom, a Unix X window version on which David Koppenhofer's psDooM is based. As psDooM was inspired by XDoom, David was inspired by Dennis Chao and Dennis was inspired by Vernor Vinge. If you are curious, check out the link to Dennis' "Doom as a tool for system administration" in the resources section.

Anyhow, the idea behind psDooM is to provide a strange alternative to process management. The monsters roaming the halls will have a red process ID floating above their heads along with the last seven characters of the command name.

An IWAD is required to run psDooM, specifically the Doom 1, Doom 2, or Ultimate Doom. The shareware Doom 1 IWAD will also work. If you don't happen to have your own Doom WAD, you can download a copy from the http://www.doomworld.com site. I visited the site and picked up a copy of the file.

Notice the "-2" flag above. By default, you'll find the screen quite small. This flag will increase the size of your default screen. If you've never played Doom before, I must warn you, mes amis, that it can get a little violent. Monsters and bad buys roam the halls and your life hangs in the balance. Wounding a process monster is equivalent to renicing that process ( renice +5 ). Keep shooting and you will kill the process. System permissions are honoured, however. You can kill a monster process that belongs to another user (or the system) but it will be resurrected. Only your own processes will stay dead.

Perhaps you might want to consider not doing this as root ever, and certainly not on the corporate server.

Once again, mes amis, it looks as though the clock has been racing toward closing time. It has been wonderful having you here at Chez Marcel. I certainly hope you enjoyed your exploration of process administration. I must admit that I am still a little shaken from my psDooM experience. Perhaps a little more wine to soothe the nerves. François, if you would be so kind as to refill our guests' wine glasses and, of course, mine.