gnopstree - Process tree display and manipulation under GNU/GNOME.
gnopstree [--help ]
gnopstree [--version ]
gnopstree [--interval=time-in-seconds ]
[--allprocs ]
[-metoo ]
[--kernel ]
[--debug =integer-debug-value ]
gnopstree is sort of an GNOME front end to ps(1), kill(1),
and nice (and maybe uptime(1) too). It is perhaps an X-windows
version of a continually running pstree(1) with the intent of
dynamically showing in color what process are running or stopped,
being spawned or zombies. The ``sort of'' part in the first sentence of
this section is that for efficiency, ps is not in fact called in
generating the tree display. And for that matter, neither are the
command line versions of kill(1), or nice(1).
The main part of the display show processes as a tree or forest, the roots of the tree are on the left-hand side and the leaf processes (with no children) are on the right-hand side. Which processes shown is determined various settings. Once can select viewing all processes, or processes owned by specific users, and possibly kernel processes as well.
Process status (running, sleeping, stopped, etc.) of shown processes is indicated by a color.
Within each level, processes are grouped so that those with the same parent process id are grouped together. Within this, processes are arranged by userid with lower number uid's appearing towards the top.
This means root processes always appear at the extreme top, assuming the processes' parent was also a root process. Finally, among processes that have a common parent (or no parent) and belong to the same userid, those with lower process numbers appear towards the top. In general, the order of children is the order in which they were spawned, with the older processes appearing towards towards the top.
In contrast to pstree and many tree-widget based programs, the
overall tree display uses diagonal lines, and some effort is made to
effectively use the full 2-dimensional area of the screen by balancing
levels and centering the children of a node between their parent. But
since a goal of the program is to visually give a picture of
what's going on, when possible processes are kept close to their
parents so one needn't scroll around too much and so that doesn't
there isn't a lot of redrawing as processes are created or destroyed.
One can click on a process to get more information (via ps) about
that process, send a signal to the process, or set its priority
(assuming you have the permission to do so).
The majority of processes in a system, one hopes, are sleeping processes. The color to be selected for uid's of sleeping process can be specified in the X RESOURCES section. If however a color is not specified, one is chosen at random. Generally, all processes belonging to a given user will be a unique color.
As the Perl motto goes ``There's more than one way to do it,'' and that's true here as well. All of the following options can be set via X RESOURCES, and many values can be toggled in the course of the execution of the program through MENUS, DIALOGS, AND BUTTONS.
But setting ``help'' or the ``version'' as a resource does not make much sense as these are typically not done in the normal course of things, so a couple things are unique to this section.
Options can be abbreviated to the extent that they are unique.
So --help can be abbreviated as short as -h.
interval resource, and can be changed via the Refresh Rate Dialog.
kernel resource.
allprocs resource, and can be changed at runtime through
the Kernel radio buttons.
beep resource, and can be
changed at runtime through a Beep toggle button.
Quick button initially on. This value can also set
more statically in X using the quick resource.
stopped resource.
idle resource.
running resource.
zombie resource.
selected resource.
ps command which can be run to give information about a process.
This value can also set more statically in X using the pscmdline
resource. See that section for more information.
ps command which can be run to give information about a process.
This value can also set more statically in X using the pscmdinfo
resource. See that section for more information.
-geometry), the window
name (-name), the foreground and background colors (-fg,
-bg), the font used (-fn), whether the window starts out
iconified (-iconic) and so on.
The main window is divided into three sections:
Each of the pop up menus has its own context-specific help.
Options -allprocs, -kernel, -beep, and -zoomed mentioned
above in Options, set the initial state for various display
parameters. In addition, there are buttons which allow toggling
between the two states. When a button is depressed (or looks
depressed), the feature described below is ``on.''
togglebeep().
The tune to play can be set by resources beepup and beepdown.
Depending on the shifting activity of processes, you might have to be quick though to get the right one!
The default behavior is to be nice to the process and send it a
TERM signal. However serial killers and die-hard sysadmins can
arrange for the default signal to be KILL (-9) or another signal
using the Set Quick Command Dialog.
Having Quick button depressed will also cause the default signal in the process popup window to be set to that value.
toggleprocs() and togglekernel().
Only push button in this group can be selected at any given time.
zoom().
There is probably room for much much much more improvement here. I'm not a guiologist. Some of the ``features'' are inherited that I didn't have the heart to remove, although I rarely use them: the beep and zoom ``features'' in particular. And the GUI that has been added is pretty bare bones. For example perhaps a ``combo box'' (combination text entry and slider) for setting the refresh interval might be more to folks liking. The debugging options could be a bunch of push buttons in a menu rather than entering as a number.
When a process name is selected on the process-tree canvas, a dialog
box for that process pops up if it is not already open. If it is already
open and a different process is selected underneath, the process
information changes. In order to show the which process is selected
on process-tree canvas, the process name changes color to the color
specified by the selected resource.
The top part of the the Process Dialog inside the Status area frame, generally lists information about the process. The top entry gives the command that was run to get the information listed below that. You can click on the ``status command:'' button to bring up the Set Process Status Cmd Dialog.
The middle frame of the dialog, ``Signal area'' can be used to set the priority of the process or process group and can be used to send a signal to the process or process group.
On the left side is scrollable list of signals which can be sent to
the process. This list is automatically generated when the program was
compiled via the program makesig.pl. The list of signals is in
sorted order, but the most common signals are listed at the top
according to my preference. If the Quick Kill toggle button had
been depressed, the signal selected in the Set Quick Command Dialog is selected. Otherwise ``NO ACTION'' will be selected and you
will have to select a signal if you want to send a signal to a
process.
To the right of the scrollable list of signals is a slider which can be used to set the process priority. The initial value is the value at the time for that process at the time the process was selected.
There is a notion in Unix called a process group which is a group of processes that are usually related in some way; perhaps they were spawned from a common parent. Instead of sending a kill signal to a specific process, the signal can be sent to the set process of processes in the process group. Likewise instead of setting the priority for a single process it can be set for the process group. The process group toggle button in the process dialog is used to indicate that a signal or priority should be applied to the process group rather than the process that is selected.
Note that in order for a kill signal or a change in priority to
take effect, you may need sufficient permission to do so. This is no
different than say if you were to run kill(1) or nice(1) from a
shell.
If there is a problem in changing the priority (and the program catches you), the old value is kept.
In the bottom frame you can run any arbitrary command (that you have permission to run). The template is again the command that is set from Set Quick Cmd Dialog, but you can edit the command.
To be completed...
The Set Refresh Rate Menu is used to set how frequently this program should retrieve process information. The units displayed are in seconds.
Changing the refresh rate does not have an immediate effect, but takes effect the next time the polling occurs.
No matter what the refresh rate interval is set to, the display is updated only when it is visible--this program can consume lots of CPU time. = head2 Set Process Status Cmd Dialog
In the top part of the process popup window, process information is
shown by running a ``ps''-like program. What command to invoke is
determined initially by the value associated with the -pscmdline
option or the pscmdline X resource if it is not set as a command
option, or if neither of these are set then by a platform-specific
ps command string set when this gnopstree was configured and compiled.
Well, this is not the whole truth. Having written all of the above, you can dynamically change this here as the program is running! Should you want different information or in a different format, here is where you can customize.
The ``ps''-like command string should have %d or %ld as a
placeholder for the process id or ``pid''. Chances are that the command
string will want to refer to the process id somewhere. The process id
of the selected process will be substituted for the first occurrence of
%d or %ld (if any) found. After substitution, the command string
is executed and the output, which might be several lines, will be put
in the scrolled window.
Example (for Linux):
/bin/ps w %d
If you have lsof installed, another interesting possibility
is:
lsof -p %d
When the all radio button is depressed, the program generally shows
all processes. It is possible that on some systems the program has
not been compiled in a way to show processes other than the ones you
own. On some systems there is a Kernel button as well and this
shows all processes as well as additional kernel processes.
When the user radio button is depressed, the program shows only
some portion of all the processes, initially the processes associated
with the userid that invokes the program. However you can change that
with the ``Set Watch User'' dialog box.
On systems that have a regular-expression library and where the program has been compiled to support patterns, there will be a ``regular expression'' toggle button which allows one to select a regular expression to filter out which users to show. See your system documentation for the regular-expression syntax. Selection by regular expression may slow the program down a bit, so it should be used with caution for complex patterns and systems with a very large number of processes.
When exact match is indicated, the user name only changes if the
newly-entered one is a name known on the system. If regular
expression is selected the entry field changes only if the regular
expression syntactically correct. If there is an error in entry the
old value is kept and method of matching (pattern-match or not) is
kept. Error messages are displayed in the main window status area.
Each user in the process tree is assigned a color, often a different color. If a color assignment is not specified explicitly, the program will generate a color based on a hash of the uid. Sometimes this is a pleasing color; sometimes it is ghastly. Some effort is made to select a color that has enough contrast with the background canvas color.
The Set User Color Menu can be used to change the color associated a given user in the process tree display interactively. You enter a user name or a userid in the top entry field, but you make sure the option menu on the extreme left is selected correctly. You can also see and retrieve the color value for a user/userid by clicking the ``get'' button on the right-hand side.
In the bottom entry you specify some color. This can be done using via a gnome color picker on the left or by specifying an X color name like ``blue'' or ``RGB:D0/A0/70''. A sample of the color selected in the text area should appear to the left. If this color doesn't change or isn't right, then either there is an error in parsing the color name or perhaps you haven't hit enter in the text area to signal completion of your entry.
Error messages for this dialog appear in the main window status area.
The root user and other users with uid 0 are by default assigned the color black.
If you should be so unfortunate as to want to debug this program, you can set this integer value and output should appear on stdout. So if you set debugging you should have some way to see stdout of this program. For example running this command from a window menu is probably a lose.
The debug value is interpreted as a bitstring the individual bits determine what's displayed. The bit values are:
1 for callbacks and events handling 2 for display debug messages 4 for menu-oriented messages 8 for the virtual position in the tree-level 16 for topological sorting of pids and numeric pid sorting messages 32 for drawing 64 for canvas-item widget creating and hiding 128 for information on whether we need to redraw the display
THE INFORMATION IN THIS SECTION IS A HOLD OVER FROM THE OLDER PROGRAM XPS. This section needs rewriting if not also some coding to set resources.
THE INFORMATION IN THIS SECTION IS A HOLD OVER FROM THE OLDER PROGRAM XPS. This section needs rewriting if not also some coding.
The program lies about the state of gnopstree itself since it is always running at the time it checks.
The program can consume a bit of resources both in itself and in the X server. Of course, the fewer processes that need to be tracked and the slower the refresh interval, the less run time consumed.
However some effort is made to not gather or redraw the display when not shown. The program tries to track whether it is iconified or if the process tree display window is fully obscured. If so, the program will not try to obtain data or refresh its display. But unless I've coded the program properly, it's possible for the program to think it is not visible when in fact it is.
As a further measure to reduce overhead, the program takes a sum of all of the process ID's, the sum of the process states and number of nodes and will not update its process-tree display if these sums haven't changed. But it is possible that the sum can be the same even though things have changed.
There is a debug menu; if debug values are set, debugging output will appear in standard output. Debugging values are a series of bits. Look in common.h of the source code for the values of the bits.
xps(1) http://motif-pstree.sourceforge.net , ps(1), pstree(1), kill(1), nice(1), uptime(1).
Another interesting package similar to this one is George MacDonald's
(gmd@orbit2orbit.com) program, treeps. That can be obtained at
http://www.treeps.org .
At times, lines from a prodigious parent with a short label name (like
nfsd) will cross over a sibling with a longer name (like
rpc.mountd). I think the program still core dumps occasionally.
Some process tables are fixed in size, somewhere at around 1,000 processes. Perhaps some will consider this a bug, but the display algorithm is not linear. As things grow the redisplay will slow down the program will consume quite a bit of CPU time. The whole paradigm of this program may not be suitable for displaying thousands of processes.
Just about everything could be improved: configuration management, tree layout, GUI design, toolkit used (via gtk+), algorithms, more platforms supported. See the file TODO distributed with the source.
The way process selection is done may be hokey in that the names of the processes aren't really widgets at all but strings drawn on a canvas so when you click on a process, in fact the program is doing its own range searching to figure out what node is meant at the mouse position. That is, there is no callback for the ``widget'' just the overall canvas! That is why for example we can't, say, put a box around the selected process but change very limited things like the color (or the font) of the string.
The current version is maintained (or not) by rocky@panix.com. However, this code reflects the work of a number of people.
Derek Lieber wrote the first version of the code for the now defunct IBM RT/PC. Although just about everything has been rewritten and extended, many of the key ideas come from this: showing a process tree from left to right, changing the color of the process to show process activity, allowing a process to be selected on the canvas and then renice'd or kill'ed.
Subsequently Steve James added the first Motif code, although nothing
in the way of command menus, dialog boxes, push buttons, or scroll
windows or signal menus. Mark Kennedy extended the code to allow
users to customize the pop up list via an X resources file, and allow
a user-specified set of signals that could be sent to processes. (This
code is has been completely replaced although the signal-list data
structure still exists.) John Prager added the code to list different
userids in different colors, sort by user within tree levels and beep
when the processes change. Also he put more information in the popup
status and replaced some of the terminal shells (like aixterm) with
user names.
Rocky Bernstein added code to restrict the process tree to a single
selectable user process, added even more info in the popup about a
process (via ps), all the other dialogs, sorting by userid and
process ID, the Motif scroll window canvas, toggle buttons, and this
initial manual page. He also ported to Solaris and Linux, wrote the
current tree-layout algorithm, and did major restructuring and
rewriting to separate the code into machine-dependent components in
separate directories. He revised to use automake, generate
machine-dependent signal lists, and finally ported from Motif to
GNOME.
Kazuki Sakamoto (sakamoto@cec.co.jp, sakamoto@netbsd.org) ported to NetBSD. See also the file THANKS for a more complete list of contributors.