psDooM

Synopsis:

psDooM is a process monitor and manager for *nix systems. It could be considered a graphical interface to the 'ps', 'renice', and 'kill' commands. psDooM is based on XDoom, which is based on id Software's 'Doom'.

History:

When id Software released the source code to Doom in December 1997, eager programmers spawned many new versions of Doom with new features. XDoom by Udo Munk is one such version. Not only does it have some advanced functionality, it runs on several different computer platforms. id Software eventually re-released the Doom source under the GNU General Public Licence instead of the more restrictive non-commercial licence it was originally licenced under.

At the University of New Mexico, Dennis Chao took the GPL'd sources of XDoom and modified them to create a proof-of-concept program for the web page "Doom as a tool for system administration". He added code so that processes running on the system would be instantiated as monsters, and wounding and killing them corresponds to renicing and killing the processes.

After reading a story on Slashdot about Dennis' project and visiting the UNM site, David Koppenhofer decided to take a look at the program and possibly enhance and customize it as Dennis suggested on his web page. psDooM was born.

Goals:

1. Continue to add functionality to the process manager, such as the ability to send various kill signals and a way to shut down the machine cleanly from the program.
2. Add networking support so multiple admins can work the machine at the same time and/or remotely administer a machine.
3. Everything else in the TODO file.
4. Possibly make other interfaces besides one to 'ps', such as a file management module.
5. Make psDooM the de-facto standard for graphical process manipulation on the *nix platform. :-)

Description:

Please note that this information applies to the latest release of psDooM, whether it is a full release or development snapshot. Older releases may have different behavior than what is described here. Consult the CHANGELOG for details of version differences.

As stated above, psDooM is a process monitor and manager for *nix systems. While psDooM is not as full-featured as some other process utilities, it is certainly functional for many tasks. Additionally, it has a unique (and quite possibly familiar) user interface: Doom.

Since psDooM is based on XDoom's codebase, psDooM can do anything that XDoom can, with a few cavaets:

• Demos recorded with psDooM have not been tested for compatability with XDoom and other Doom ports.
• Save games aren't compatable with XDoom (and probably other Doom ports).
• Netgames won't work on levels that have processes spawned on them, due to consistancy check errors. Netgames on levels without monsters representing processes should work, but this is untested as well.

psDooM can monitor processes with shareware Doom 1, registered Doom 1, Ultimate Doom, or Doom 2. 'Plutonia Experiment' and 'TNT - Evilution' will run, but no process monitoring will be done.

The first level (either E1M1 or MAP01), and only the first level, will contain monsters that represent processes currently running on the machine ('pid monsters'). The machine's process list is checked at regular intervals. Processes that are new since the last check are spawned as new monsters, while processes no longer running on the machine are removed from the level. Process monitoring is not done if the user is on a level other than the first one or while recording/playing a demo.

A 'pid monster' is identified by the text 'floating' in front of it. This text denotes its process id number and the last 7 characters of the process name. The text is not shown if the monster is too far away from the player or too close to the edge of the screen.

Wounding a 'pid monster' corresponds to executing a 'renice +5' on the associated process. Killing a 'pid monster' sends a 'kill -9' to the associated process. Since the renice and kill actions are done by a system call, they are governed by the permissions of the user running psDooM. For example, if a normal user, 'jschmoe', kills a 'pid monster' whose real process is owned by 'jdoe', nothing would happen to the underlying process on the machine because jschmoe doesn't have the rights to alter jdoe's processes. The 'pid monster' that jschmoe killed will be resurrected in psDooM during the next process check. The resurrection denotes that the process on the machine never really went away; its Doom representation was only temporarily stopped from moving around.

In the original implementation of the program, 'pid monsters' could be killed not only by the program's user, but also by other 'pid monsters' and normal Doom monsters on the level. The reasoning behind this behavior was that "on very heavily-loaded machines, it is not uncommon for the OS to kill random processes." Unfortunately, the number of monsters in a given area must be depressingly small in order for them to avoid both intentional infighting and friendly fire. Since monsters would tend to kill each other off until only a few remained in the area, the user was severely hampered in the ability to orderly control processes on the machine. Therefore, the default behavior of psDooM is to ensure the player is the only character in the game who can wound and kill 'pid monsters'. This avoids accidental process deaths from monster infighting. Unfortunately, it doesn't prevent accidental process deaths from a user's poor aim. ;-} The original behavior of 'pid monsters' being as vunerable as other monsters may be enabled with a command line flag.

The 'pid monster' locations depend on what version of Doom is used and whether the custom process management levels are loaded. Only registered Doom, Ultimite Doom, and Doom 2 may use the custom levels, as they contain items and textures not in the shareware version.

Locations of the 'pid monsters' within the levels are as follows:

• For shareware Doom 1, and registered Doom 1 or Ultimite Doom without the custom level:
  psDooM spawns the 'pid monsters' in the 'hidden' courtyard on E1M1. To get there, go through the room with the zig-zag floor with poison around it and open the miscolored wall on the right, before the door to leave that room.
• For Doom 2 without the custom level:
  psDooM spawns the 'pid monsters' in the 'hidden' courtyard on MAP01. To get there, activate the switch to (and get on) the lift in the room before the exit. Then, once the lift raises, activate the rear wall and walk into that secret alcove. When you leave the lift, a door to the courtyard will have opened on the right side of the room, past the window on the right.
• For the custom levels:
  psDooM spawns the administrator in a room with equiptment and weapons. The switch in the middle of the room exits the level, and the three doors lead to rooms containing 'pid monsters'.

psDooM is somewhat flexible, as the user has several options to modify its behavoir.

• The user can tell psDooM to show only certain user(s) processes. If no usernames are specified, psDooM uses sensible defaults.
• Process monitoring can be entirely disabled. This is handy if one wants to play an E1M1 or MAP01 level that isn't set up for process monitoring.
• The system calls to 'renice' and 'kill' when 'pid monsters' are wounded and killed can be suppressed. This is good if one only wants to monitor processes, not manage them.
• A '-nomonsters' that is persistant across new games and level warps may be enabled. Note that 'pid monsters' are not affected by '-nomonsters'. Just disable process monitoring altogether if you don't want them to show up.
• Item respawning, as in '-altdeath', may be enabled for normal gameplay. Really handy to keep those naughty 'pid monsters' in line.

The XDoom distribution includes a graphical front-end to xdoom, called xdlaunch. It allows the user to specify XDoom command line flags by clicking option boxes and using dropdown lists. This utility has been renamed to ps-xdlaunch and modified to run psDooM. Also, a place in the front-end was added so a user can manually type additional command line flags to pass to ps-xdoom. psDooM-specific options can be shown by pressing a button in ps-xdlaunch. This utility requires TCL/TK.

Disclaimer:

I will not assume any liability for damage caused from running this code. Especially if you are running it as root. In fact, we both know that this will cause damage to the system, and that's why you want to try it. You have been warned.

From the GNU GPL:

NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION. 

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES
SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE
WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 
      

Problem Reports:

If psDooM won't compile for you, please see the note about A Common Compilation Error

If you find a problem with psDooM, you could e-mail me about it. You could also go to the psDooM SourceForge Project Page and use the facilities there (like 'bug report', 'support request', etc). Before you do so, please be sure that it is a psDooM problem rather than an XDoom issue. The easiest way to tell the difference is to run XDoom with the same level and options (if at all possible). If the problem occurs there as well, it's XDoom's fault, not psDooM's. Obviously, if the problem involves any of the psDooM-specific command line flags or 'pid monsters', it is a psDooM-related issue. :-) I cannot guarantee that I can solve your problem. I'm doing this in my spare time for the fun of it; this software is provided on AS IS basis.

Copyright © 2000 David Koppenhofer