A Process Smorgasbord

François, vite! Our guests will be here any moment. Quoi? You say you already have prepared everything? Excellent, François! I see you have 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.

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. 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 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. 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 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:

init-+-apmd
     |-atd
     |-bdflush
     |-cardmgr
     |-crond
     |-gpm
     |-kalarmd
     |-kapmd
     |-kappdock-+-wmWeather
     |          `-wmmultipop3
     |-kdeinit-+-artsd
     |         |-autorun
     |         |-kdeinit
     |         |-kdeinit---2*[bash]
     |         |-kdeinit---bash
     |         |-kdeinit-+-bash---lavaps

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 option displays a forest view through which you can see the process trees. A little joke, mes amis.

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 URL: www.orbit2orbit.com/gmd/tps/treepsfm.html.

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

The initial view is of your own processes as launched from init, and this 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 options of renicing the process, viewing its man page and so on.

From the bar of buttons on the top, click the various selections. Aside from a view of your own processes, you can choose to see the dæmon processes or simply everything. If you click the information button (the one with an “i” on it), your mouse pointer changes to an “i” as well. Click any process, and an information window appears with more details about the running process than you would have thought were there. From that window, you can drill down even further. Click the File/Dir button, and you can 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 called System Info, which brings up the System Information App Launcher. From this button-laden window, you quickly can view tons of information about your system, from your routing table to loaded modules, kernel level, PCI devices, uptime, disk partitions, runlevels and so on.

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 toward 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.

The idea here 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 web site (www.isi.edu/~johnh/SOFTWARE/LAVAPS/index.html) and picking up a copy of the package.

For the Red Hat users out there, prepackaged 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:

tar -xzvf lavaps-1.20.tar.gz
cd lavaps-1.20
./configure
make
su -c make install

To start your lava lamp, type lavaps &. You'll see a small lava lamp appear on your desktop. Right-click, and a menu pops up offering a number of options. The proc menu tells you the process ID and the name of the process. It also allows you to send various signals (such as 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 1024 × 768 display. Overriding this requires that you set X resources. This is done easily 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 3-D 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 System 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” (see Resources).

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

Source tarballs are available from the psDooM web site, but the easiest way to install psDooM is to pick up the precompiled binaries. Installation is fairly simple: run the install.sh script:

tar -xzvf psdoom-2000.05.03-bin.tar.gz
cd psdoom-bin
su -c "./install.sh"

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

unzip shareware_doom_iwad.zip
su -c cp DOOM1.WAD /usr/local/games/psdoom/doom1.wad

That's it. Now, we are ready to run psDooM:

cd /usr/local/games/psdoom
./psdoom -2

Notice the -2 option above. By default, you'll find the screen quite small. This option increases 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 boys 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 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' wineglasses and, of course, mine. Until next month. A votre santé! Bon appétit!

Resources