                             TOP
                         Version 3.3

                       William LeFebvre
		     and a cast of dozens


FREQUENTLY ASKED QUESTIONS AND THEIR ANSWERS

1. "We just upgraded our operating system to version 99.9.9.9 and top
   broke.  What should we do?"

   Recompile.  Top is very sensitive to changes in internal kernel data
   structures.  It is not uncommon for a new version of the operating
   system to include changes to kernel data structures.

2. "I tried compiling top under SunOS version 4.1.3 and it got compile
   time errors.  Is there a patch?"

   If you try compiling top in a "System V environment" under SunOS
   (that is, /usr/5bin is before /usr/bin on your path) then the 
   compilation will fail.  This is mostly due to the fact that top
   thinks its being compiled on a System V machine when it really isn't.
   The only solution is to put /usr/bin and /usr/ucb before /usr/5bin
   on your path and try again.

3. "Under Solaris 2, when I run top as root it only shows root processes.
   It refuses to show anything else.  What do I do?"

   You probably compiled it with /usr/ucb/cc instead of the real C
   compiler.  /usr/ucb/cc is a cc front end that compiles programs in
   BSD source-level compatability mode.  You do not want that.  Make
   sure that /usr/ucb is not on your path and try compiling top again.

4. "Under Solaris 2, when I try to run top it complains that it can't
   open the library "libucb.so.1".  So I changed the LIBS line in
   m_sunos5.c to include -R/usr/ucblib to make sure that the dynamic
   linker will look there when top runs.  I figured this was just an
   oversight.  Was I right?"

   No, you were not right.  As distributed, top requires NO alterations
   for successful compilation and operations under Solaris 2.0, 2.1, 2.2,
   2.3, and 2.4.  You probably compiled top with /usr/ucb/cc instead of
   the real C compiler.  See FAQ #3 for more details.

5. "Top is (not) displaying idle processes and I don't (do) want it to."

   This default has only changed about a dozen times, and I finally got
   tired of people whining about it.  Go read the manual page for the
   current version and pay special attention to the description of the
   "TOP" environment variable.

6. "We have so much memory in our machine that the memory status display
   (the fourth line) ends up being longer than 80 characters.  This
   completely messes up top's output.  Is there a patch?"

   Most modules have been changed to use new memory formatting functions
   which will display large values in terms of megabytes instead of
   kilobytes.  This should fix all occurences of this problem.  If you
   encounter a system where this large memory display overflow is still
   occurring, please let me know (send mail to <lefebvre@dis.anl.gov>).

7. "When I run top on my SVR4-derived operating system, it displays all
   the system information at the top but does not display any process
   information (or only displayes process information for my own
   processes).  Yet when I run it as root, everything works fine."

   Your system probably uses the pseudo file system "/proc", which is
   by default only accessible by root.  Top needs to be installed setuid
   root on such systems if it is going to function correctly for normal
   users.

8. "Configure said that it saw /proc and is recommending that I install
   top setuid root.  Is there any way around this?  Is it safe?"

   There is no way around it.  Complain to POSIX.  Every effort has been
   made to make top a secure setuid program.  However, we cannot guarantee
   that there are no security problems associated with this configuration.
   The places where top is most vulnerable are the builtin kill and renice
   commands.  There is no internal top command that causes top to start
   a shell as a subprocess.  Some SVR4 systems may contain a bug that
   enables a user to renice his own processes downward (to lower nice
   values that are more favorable for the process).  This problem has
   been fixed for the Solaris 2.x modules, but may still exist in others.
   We will hopefully fix this up in the next release.

9. "Top is not showing the command names.  Everything else is fine, just
   no command names.  What's wrong?"

   This usually occurs when top is compiled under one revision of the
   operating system (say SunOS 4.1.3) but run under another (say
   SunOS 4.1.3C_U1_B3_V9_Z47_*HIKE*).  What has happened is that the
   user structure is different, and the location of the array that
   contains the command name is not at the same offset.  Other than
   maintaining separate executables for every variant of the operating
   system, there is little you can do about this.  This will also occur
   if you compile top on one machine sub-architecture (i.e.: sun4c) and
   try to run the resulting executable on a different sub-architecture
   (i.e.: sun4m).  Read "INSTALL" for more details.

10."Is there a module that will make top work under AIX?"

   Not at the current time.  Many people have started this project but
   none have yet to finish.  That may say something about the difficulty
   of the task......

11."I tried to compile top with gcc and it doesn't work (either compilation
   errors in the include files or a non-working executable).  What's wrong?"

   Gnu CC likes very much to use its own include files.  Not being a gcc
   expert, I can't explain why it does this.  But I can tell you that 
   if you upgrade your operating system (say from SunOS 4.1.2 to SunOS
   4.1.3) after installing gcc, then the include files that gcc uses will
   be incorrect, especially those found in the "sys" directory.  Your
   choices are:  (1) rebuild and reinstall the "standard" include files
   for gcc (no I don't know how to do this), (2) compile machine.c with
   "CFLAGS=-I/usr/include" then make the rest of the object files
   normally, or (3) use "cc".

12."Top is not written in ANSI C.  Do you ever plan to change that?"

   Top predates ANSI C by about 5 years.  Yeah, it'll get "fixed"
   eventually (if you can call that "fixing").  Maybe in 3.4, maybe
   not until 4.0.  I'm not big on standards.

13."To whom do I report problems with top?"

   First, look through all the FAQ answers.  Chances are an answer to
   your question can be found in this file.  If you still have an
   unanswered question, you can send mail to "lefebvre@dis.anl.gov".
   If it looks like the problem is machine-specific, I will forward the
   report along to the module's author.  If you would like to converse
   directly with the module author, the authors' names are listed at the
   beginning of the module .c file in the "machine" directory.

14."Are you superstitious?"

   Not usually, no.   :-)
