PROCTOOL IS NO LONGER SUPPORTED IN ANY WAY. USE IT AT YOUR OWN RISK. YOU MIGHT BE ABLE TO USE THIS INFORMATION TO FIND WHY IT IS FAILING, BUT THERE IS NO WAY TO FIX IT. PLEASE DO NOT SEND REPORTS OF PROBLEMS TO ANYONE - THERE IS NO ONE WHO CAN HELP.
To install proctool, download the compressed tarball via anonymous ftp from:
and as root, unpack into an installation directory, such as /opt:
# cd /opt # gunzip proctool_1999_04.tar.gz | tar xvf -
This will unpack a directory which looks like:
proctool/ | .-------------------------------. | | | | bin/ README lib/ docs/ | .--------------------------. | | | | proctool* arch1/ arch2/ ... archN/ | .----------. | | proctool* pmon*
If the previous step was executed as root, then the permissions on the files will already be correct. Otherwise, the executables must be made setuid to root as demonstrated below:
% cd /opt/proctool/ % su root passwd: # chown root bin/*/pmon # chmod u+s bin/*/pmon # ^D % ls -l bin/*/pmon -r-sr-xr-x 1 root staff 102824 Feb 18 02:40 bin/5.5_sparc32/pmon -r-sr-xr-x 1 root staff 86204 Feb 18 02:40 bin/5.6_intel32/pmon -r-sr-xr-x 1 root staff 106672 Feb 18 02:40 bin/5.6_sparc32/pmon -r-sr-xr-x 1 root staff 106624 Feb 18 02:40 bin/5.7_sparc32/pmon -r-sr-xr-x 1 root staff 128496 Feb 18 02:40 bin/5.7_sparc64/pmon
The appropriate proctool binary can be invoked by directly executing the script in the bin directory, for example:
% /opt/proctool/bin/proctool &
Alternatively, you can copy the invocation script to some location already in your $PATH. To do this, you must edit the script to specify the real installation directory.
A common configuration might be to copy the invocation script to a generally available directory, like /usr/local/bin so that users won't have to update their $PATH environment variable. [Refer to the directions at the beginning of the "proctool" script for full instructions, including a generalization which enables remote execution.]
As mentioned previously, the various proctool binaries can be invoked by directly executing the script in the bin directory, for example:
% /opt/proctool/bin/proctool &
Alternately, you can set your $PATH environment variable to include the path to the proctool script, for example:
% setenv PATH ($PATH /opt/proctool/bin)
$ PATH=$PATH:/opt/proctool/bin $ export PATH
You can override the normal X resources using the $HOME/.Xdefaults file:
proctool.*.background: proctool.*.title.font: proctool.*.caption.font: proctool.*.Caption.font: proctool.*.font: proctool.*.TextEdit.InputFocusColor: proctool.*.InputFocusColor: proctool.*.TextEdit.font:
And you can override some proctool specific resources the in the same location:
proctool.process.font: proctool.alert.font: proctool.system.font: proctool.graph_title.font: proctool.graph_legend.font:
Bug Reporting NOTICE!!!
PROCTOOL IS NO LONGER SUPPORTED IN ANY WAY. USE IT AT YOUR OWN RISK. YOU MIGHT BE ABLE TO USE THIS INFORMATION TO FIND WHY IT IS FAILING, BUT THERE IS NO WAY TO FIX IT. PLEASE DO NOT SEND REPORTS OF PROBLEMS TO ANYONE - THERE IS NO ONE WHO CAN HELP
proctool version number (ie. 2.6.1) Solaris version info (ie. uname -a) a description of the steps needed to reproduce the problem
If the problem isn't easy to reproduce, and if either of the programs dump core, then please include the core file in the bug report (or at least include a traceback from dbx or adb).
If the display program (proctool) is dying without leaving a core file, you can invoke it under a debugger and ask for a traceback when it quits. This could also be done with the monitor program (pmon), but is more difficult since you would have to attach to the running program.
For pmon problems, try setting the environment variable PROCTOOL_DEBUG and re-running. This will generally cause the program to dump information about what went wrong and what it was doing.
One other useful debugging technique is to run Proctool under truss; and include the last few hundred lines of output in the bug report, for example:
$ truss -f proctool > /tmp/bugreport 2>&1
This release deals more gracefully with different X-servers (and most notably, automatically trying alternate fonts). It still, however, is not compatible with the "fvwm" window manager.
Proctool now displays the process start date using a 4-digit year in order to fix a small Y2K bug.
The $HOME/.proc.init file is now saved in ASCII in order to make it sharable between X86, SPARC/32, and SPARC/64 versions. The previous binary file would only work for one architecture at a time. Old config files are still readable, but they will always be rewritten in the new format.
Please keep in mind that proctool is provided "as is" and is NOT a supported product.