xref: /netbsd-src/external/bsd/top/dist/FAQ (revision 10dd2532a5fc0a73e461275cb9fca28fc3013d32)
1*10dd2532Schristos                                        TOP
2*10dd2532Schristos                                  Version 3.8beta1
3*10dd2532Schristos
4*10dd2532Schristos                                  William LeFebvre
5*10dd2532Schristos                             with much help from others
6*10dd2532Schristos
7*10dd2532Schristos                    Frequently Asked Questions and their Answers
8*10dd2532Schristos
9*10dd2532Schristos
10*10dd2532Schristos
11*10dd2532Schristos     GENERAL
12*10dd2532Schristos
13*10dd2532Schristos 1.  What is top?
14*10dd2532Schristos
15*10dd2532Schristos     Top provies the user with a regularly updated display showing
16*10dd2532Schristos     information about the system and its top cpu-using processes. Think
17*10dd2532Schristos     of it as a full-screen "ps" output that gets updated at regular
18*10dd2532Schristos     intervals.
19*10dd2532Schristos
20*10dd2532Schristos 2.  Where do I get the latest version of top?
21*10dd2532Schristos
22*10dd2532Schristos     The official site for top is "ftp.unixtop.org" in the directory
23*10dd2532Schristos     "/pub/top". Top is also a SourceForge project, and the most recent
24*10dd2532Schristos     releases are available on any of the SourceForge mirrors. The
25*10dd2532Schristos     SourceForge project page is at
26*10dd2532Schristos     http://sourceforge.net/projects/unixtop.
27*10dd2532Schristos
28*10dd2532Schristos 3.  Is there a web page for top?
29*10dd2532Schristos
30*10dd2532Schristos     Yes. Point your browser at http://www.unixtop.org. It includes all
31*10dd2532Schristos     documentation, a nice interactive display which describes the various
32*10dd2532Schristos     components of the output of top, web-based retrieval of the package,
33*10dd2532Schristos     year 2000 information, and other neat stuff.
34*10dd2532Schristos
35*10dd2532Schristos 4.  Is there a mailing list or on-line bulletin board for top?
36*10dd2532Schristos
37*10dd2532Schristos     There is a mailing list used for general announcements regarding top,
38*10dd2532Schristos     including new releases. This mailing list is available to sourceforge
39*10dd2532Schristos     members and can be accessed from the unixtop sourceforge project
40*10dd2532Schristos     page. Visit SourceForge and search for the project "unixtop", then
41*10dd2532Schristos     click on "mailing lists". There are also on-line forums available
42*10dd2532Schristos     through SourceForge where members can post questions and comments.
43*10dd2532Schristos
44*10dd2532Schristos 5.  What about Year 2000 compliance?
45*10dd2532Schristos
46*10dd2532Schristos     Top did not experience any problems with the transition to the year
47*10dd2532Schristos     2000. A full statement concerning top and the year 2000 can be found
48*10dd2532Schristos     in the file "Y2K" included with the distribution.
49*10dd2532Schristos
50*10dd2532Schristos 6.  Will there be another major release of top? Will there be a top
51*10dd2532Schristos     version 4?
52*10dd2532Schristos
53*10dd2532Schristos     I have some great ideas for the next major release of top, and I very
54*10dd2532Schristos     much want to make those ideas a reality. What I don't have much of
55*10dd2532Schristos     these days is free time. But I will keep poking at it and I hope to
56*10dd2532Schristos     have top version 4.0 ready by the fall of 2006.
57*10dd2532Schristos
58*10dd2532Schristos 7.  Does top really support multi-processor systems?
59*10dd2532Schristos
60*10dd2532Schristos     On platforms that support multiple processors, top is able to detect
61*10dd2532Schristos     and correctly summarize the information about those processors. What
62*10dd2532Schristos     top does not do is break down the cpu states summary (the third line
63*10dd2532Schristos     of the display) by cpu. Instead it collects the cpu state information
64*10dd2532Schristos     from all processors and combines them in to a single line. Some
65*10dd2532Schristos     vendors  include a modified version of top that presents this
66*10dd2532Schristos     information for each cpu. Top 3.7 may have this functionality but it
67*10dd2532Schristos     is not present in the standard top 3.6 release.
68*10dd2532Schristos
69*10dd2532Schristos 8.  Is top under CVS control? Can I access the sources via SourceForge
70*10dd2532Schristos     CVS or Subversion?
71*10dd2532Schristos
72*10dd2532Schristos     I maintain top using subversion, not CVS. Although I utilize my own
73*10dd2532Schristos     private subversion repository, it is regularly mirrored in to the
74*10dd2532Schristos     SourceForge Subversion repository. You can access the SourceForge
75*10dd2532Schristos     repository here: https://svn.unixtop.org/unixtop/top-3.
76*10dd2532Schristos
77*10dd2532Schristos
78*10dd2532Schristos     COMPILING
79*10dd2532Schristos
80*10dd2532Schristos 9.  We just upgraded our operating system to a new version and top broke.
81*10dd2532Schristos     What should we do?
82*10dd2532Schristos
83*10dd2532Schristos     Recompile it. Top is very sensitive to changes in internal kernel
84*10dd2532Schristos     data structures. It is not uncommon for a new version of the
85*10dd2532Schristos     operating system to include changes to kernel data structures.
86*10dd2532Schristos
87*10dd2532Schristos
88*10dd2532Schristos     RUNNING
89*10dd2532Schristos
90*10dd2532Schristos10.  I just finished compiling top and it works fine for root, but when I
91*10dd2532Schristos     try to run it as a regular user it either complains about files it
92*10dd2532Schristos     can't open or it doesn't display all the information it should. Did I
93*10dd2532Schristos     do something wrong?
94*10dd2532Schristos
95*10dd2532Schristos     Well, you're just not done. On many operating systems today, access
96*10dd2532Schristos     to many of the kernel memory devices and other system files is
97*10dd2532Schristos     restricted to either root or a particular group. The configure script
98*10dd2532Schristos     figures this out (usually) and makes sure that the "install" rule in
99*10dd2532Schristos     the Makefile will install top so that anyone can run it successfully.
100*10dd2532Schristos     However, you have to *install* it first. Do this with the command
101*10dd2532Schristos     "make install".
102*10dd2532Schristos
103*10dd2532Schristos11.  Top is (not) displaying idle processes and I don't (do) want it to.
104*10dd2532Schristos
105*10dd2532Schristos     This default has only changed about a dozen times, and I finally got
106*10dd2532Schristos     tired of people whining about it. Go read the manual page for the
107*10dd2532Schristos     current version and pay special attention to the description of the
108*10dd2532Schristos     "TOP" environment variable.
109*10dd2532Schristos
110*10dd2532Schristos12.  We have so much memory in our machine that the memory status display
111*10dd2532Schristos     (the fourth line) ends up being longer than 80 characters. This
112*10dd2532Schristos     completely messes up top's output. Is there a patch?
113*10dd2532Schristos
114*10dd2532Schristos     Most modules have been changed to use new memory formatting functions
115*10dd2532Schristos     which will display large values in terms of megabytes instead of
116*10dd2532Schristos     kilobytes. This should fix all occurences of this problem. Also note
117*10dd2532Schristos     that newer versions of top can use columns beyond 79, and understand
118*10dd2532Schristos     window resizes. So you can always make your window wider.
119*10dd2532Schristos
120*10dd2532Schristos13.  I tried to compile top with gcc and it doesn't work. I get
121*10dd2532Schristos     compilation errors in the include files, or I get an executable that
122*10dd2532Schristos     dumps core, or top displays incorrect numbers in some of the
123*10dd2532Schristos     displays. What's wrong?
124*10dd2532Schristos
125*10dd2532Schristos     Gnu CC likes very much to use its own include files. Not being a gcc
126*10dd2532Schristos     expert, I can't explain why it does this. But I can tell you that if
127*10dd2532Schristos     you upgrade your operating system (say from Solaris 2.6 to Solaris
128*10dd2532Schristos     2.7) after installing gcc, then the include files that gcc uses will
129*10dd2532Schristos     be incorrect, especially those found in the "sys" directory. Your
130*10dd2532Schristos     choices are: (1) rebuild and reinstall the "standard" include files
131*10dd2532Schristos     for gcc (look for scripts in the distribution called "fixincludes"
132*10dd2532Schristos     and "fixinc.svr4"), (2) compile machine.c with
133*10dd2532Schristos     "CFLAGS=-I/usr/include" then make the rest of the object files
134*10dd2532Schristos     normally, or (3) use a different compiler.
135*10dd2532Schristos
136*10dd2532Schristos14.  The cpu state percentages are all wrong, indicating that my machine
137*10dd2532Schristos     is using 95% system time when it is clearly idle. What's wrong?
138*10dd2532Schristos
139*10dd2532Schristos     This can happen if you compiled with gcc using the wrong include
140*10dd2532Schristos     files. See the previous question.
141*10dd2532Schristos
142*10dd2532Schristos
143*10dd2532Schristos     FREEBSD PROBLEMS
144*10dd2532Schristos
145*10dd2532Schristos15.  This version of top does not show individual threads with the "t" or
146*10dd2532Schristos     "H" commands. Instead it says "command not available." Why?
147*10dd2532Schristos
148*10dd2532Schristos     Previous versions of top attempted to support the display of
149*10dd2532Schristos     individual threads under FreeBSD through the use of the "t" command.
150*10dd2532Schristos     However,  the FreeBSD kernel does not supply sufficient or correct
151*10dd2532Schristos     information on the individual threads within a process. So the data
152*10dd2532Schristos     that was being displayed was incorrect and misleading. Therefore, top
153*10dd2532Schristos     version 3.8 disables the use of this command to prevent the display
154*10dd2532Schristos     of incorrect information. FreeBSD 8.0 will correctly report
155*10dd2532Schristos     per-thread information and top version 3.8 supports the use of the
156*10dd2532Schristos     "t" command for version 8.0.
157*10dd2532Schristos
158*10dd2532Schristos16.  The "f" command (to display full command lines for the processes)
159*10dd2532Schristos     does not work and instead says "command not available". Why?
160*10dd2532Schristos
161*10dd2532Schristos     The current version of top is able to use sysctl to retrieve almost
162*10dd2532Schristos     all of the information it needs without having to open /dev/kmem. The
163*10dd2532Schristos     one piece of information not available via sysctl is the full command
164*10dd2532Schristos     line of each argument. If you run top as a regular user and it cannot
165*10dd2532Schristos     open /dev/kmem (in other words, it is not installed set-gid to the
166*10dd2532Schristos     kmem group) then it will disable the "f" command. Make sure the top
167*10dd2532Schristos     binary is installed with a group ownership of "kmem" and with the
168*10dd2532Schristos     set-gid bit on if you want the "f" command to work properly.
169*10dd2532Schristos
170*10dd2532Schristos
171*10dd2532Schristos     MACOSX PROBLEMS
172*10dd2532Schristos
173*10dd2532Schristos17.  I tried to configure top on my Mac OSX system and I got an error
174*10dd2532Schristos     claiming "macosx not supported". What up?
175*10dd2532Schristos
176*10dd2532Schristos     Since I don't have full time root access to a Mac OSX system I cannot
177*10dd2532Schristos     provide effective support for the platform. MacOSX uses Mach, and it
178*10dd2532Schristos     is very difficult to extract accurate system and process information
179*10dd2532Schristos     from the system. It takes a lot of trial and error, along with root
180*10dd2532Schristos     access. I have included the most up-to-date version of the macosx
181*10dd2532Schristos     module in the distribution, but I do not claim that it works. If you
182*10dd2532Schristos     want to try to use it, you can configure with "./configure
183*10dd2532Schristos     --with-module=macosx".
184*10dd2532Schristos
185*10dd2532Schristos
186*10dd2532Schristos     SUNOS PROBLEMS
187*10dd2532Schristos
188*10dd2532Schristos18.  I tried compiling top under SunOS version 4.1.x and it got compile
189*10dd2532Schristos     time errors or run time errors. Is there a patch?
190*10dd2532Schristos
191*10dd2532Schristos     If you try compiling top in a "System V environment" under SunOS
192*10dd2532Schristos     (that is, /usr/5bin is before /usr/bin on your path) then the
193*10dd2532Schristos     compilation may fail. This is mostly due to the fact that top thinks
194*10dd2532Schristos     its being compiled on a System V machine when it really isn't. The
195*10dd2532Schristos     only solution is to put /usr/bin and /usr/ucb before /usr/5bin on
196*10dd2532Schristos     your path and try again.
197*10dd2532Schristos
198*10dd2532Schristos
199*10dd2532Schristos     SOLARIS PROBLEMS
200*10dd2532Schristos
201*10dd2532Schristos
202*10dd2532Schristos     NOTE: the most common source of problems with top under Solaris is
203*10dd2532Schristos     the result of compiling it with the wrong front end. Make sure that
204*10dd2532Schristos     /usr/ucb is not on your path before attempting to compile top under
205*10dd2532Schristos     Solaris.
206*10dd2532Schristos
207*10dd2532Schristos19.  Is there somewhere I can get a pre-compiled package?
208*10dd2532Schristos
209*10dd2532Schristos     Yes. Although I don't provide pre-compiled binaries, you can get a
210*10dd2532Schristos     Sun-style package from www.sunfreeware.com.
211*10dd2532Schristos
212*10dd2532Schristos20.  Under Solaris 2, when I type "make", the system says "language
213*10dd2532Schristos     optional software package not installed." What's going on?
214*10dd2532Schristos
215*10dd2532Schristos     You tried to compile with /usr/ucb/cc. Make sure /usr/ucb is not on
216*10dd2532Schristos     your path. Furthermore, you do not have a Sun compiler installed on
217*10dd2532Schristos     your system. You need a compiler to make top. Either Sun's C compiler
218*10dd2532Schristos     or the Gnu C compiler will work fine.
219*10dd2532Schristos
220*10dd2532Schristos21.  Under Solaris 2, when I run top as root it only shows root processes,
221*10dd2532Schristos     or it only shows processes with a PID less than 1000. It refuses to
222*10dd2532Schristos     show anything else. What do I do?
223*10dd2532Schristos
224*10dd2532Schristos     You probably compiled it with /usr/ucb/cc instead of the real C
225*10dd2532Schristos     compiler. /usr/ucb/cc is a cc front end that compiles programs in BSD
226*10dd2532Schristos     source-level compatability mode. You do not want that. Make sure that
227*10dd2532Schristos     /usr/ucb is not on your path and try compiling top again.
228*10dd2532Schristos
229*10dd2532Schristos22.  Under Solaris 2, I compiled top using what I am sure is the correct
230*10dd2532Schristos     compiler but when I try to run it it complains about missing dynamic
231*10dd2532Schristos     libraries. What is wrong?
232*10dd2532Schristos
233*10dd2532Schristos     Check to see if you have LD_LIBRARY_PATH defined in your shell. If
234*10dd2532Schristos     you do, make sure that /usr/ucblib is not on the path anywhere. Then
235*10dd2532Schristos     try compiling top again.
236*10dd2532Schristos
237*10dd2532Schristos23.  Under Solaris 2, when I try to run top it complains that it can't
238*10dd2532Schristos     open the library "libucb.so.1". So I changed the LIBS line in
239*10dd2532Schristos     m_sunos5.c to include -R/usr/ucblib to make sure that the dynamic
240*10dd2532Schristos     linker will look there when top runs. I figured this was just an
241*10dd2532Schristos     oversight. Was I right?
242*10dd2532Schristos
243*10dd2532Schristos     No, you were not right. As distributed, top requires no alterations
244*10dd2532Schristos     for successful compilation and operations under any release of
245*10dd2532Schristos     Solaris 2. You probably compiled top with /usr/ucb/cc instead of the
246*10dd2532Schristos     real C compiler. See FAQ 22 for more details.
247*10dd2532Schristos
248*10dd2532Schristos24.  On my 64-bit system some processes show up with incorrect information
249*10dd2532Schristos     (such as zero memory).
250*10dd2532Schristos
251*10dd2532Schristos     If you are running a 64-bit system, then you need to make sure that
252*10dd2532Schristos     you are running the 64-bit top binary. Top's configure script
253*10dd2532Schristos     attempts to detect 64-bit systems, and will automatically generate
254*10dd2532Schristos     both 32-bit and 64-bit binaries on such systems. If you use or
255*10dd2532Schristos     install the 32-bit binary on a 64-bit system top will still run but
256*10dd2532Schristos     will not produce the correct results. This will also happen if you
257*10dd2532Schristos     configure your distribution on a 32-bit system then compile with that
258*10dd2532Schristos     configuration on a 64-bit system. You must configure and compile on
259*10dd2532Schristos     the same system. For Sparc systems the 32-bit binary will be created
260*10dd2532Schristos     in the subdirectory "sparcv7" and the 64-bit binary will be created
261*10dd2532Schristos     in the subdirectory "sparcv9". For Intel systems the directories will
262*10dd2532Schristos     be "i386" (32-bit) and "amd64" (64-bit). In all cases a copy of
263*10dd2532Schristos     /usr/lib/isaexec is made in the main directory and called "top". This
264*10dd2532Schristos     program will choose the correct binary to run from one of these
265*10dd2532Schristos     subdirectories. See isaexec(3c) for more details.
266*10dd2532Schristos
267*10dd2532Schristos25.  Can I install both 32-bit and 64-bit binaries on a central file
268*10dd2532Schristos     server and have machines which mount it automatically use the correct
269*10dd2532Schristos     one?
270*10dd2532Schristos
271*10dd2532Schristos     Yes. If you configure and compile on a 64-bit system, top's configure
272*10dd2532Schristos     script and makefile will automatically create both 32-bit and 64-bit
273*10dd2532Schristos     binaries. The "install" rule in the makefile will install these
274*10dd2532Schristos     binaries in subdirectories of /usr/local/bin appropriate to the
275*10dd2532Schristos     architecture (sparcv7/sparcv9 or i386/amd64) then create a copy of
276*10dd2532Schristos     /usr/lib/isaexec named "top" in /usr/local/bin to ensure that the
277*10dd2532Schristos     appropriate is run when a user types "top". If you make sure that you
278*10dd2532Schristos     configure and compile on a 64-bit system, then "make install" will do
279*10dd2532Schristos     the right thing.
280*10dd2532Schristos
281*10dd2532Schristos26.  This version of top show less available swap space than previous
282*10dd2532Schristos     versions. Why does it no longer match the output of the swap summary
283*10dd2532Schristos     produced with "swap -s"?
284*10dd2532Schristos
285*10dd2532Schristos     Starting with version 3.6 of top, the amount of swap space reported
286*10dd2532Schristos     by top has been changed to reflect only disk-based swap space. The
287*10dd2532Schristos     swap summary produced with "swap -s" also includes memory-based swap
288*10dd2532Schristos     space. This changed was made for several reasons. It makes the
289*10dd2532Schristos     display under Solaris more like those of other operating systems. The
290*10dd2532Schristos     display is more what users expect (except those used to previous
291*10dd2532Schristos     versions of top). Most importantly, "swap -s" gets its data via an
292*10dd2532Schristos     undocumented system interface. Now that top no longer displays that
293*10dd2532Schristos     data it can use publically documented and maintained system
294*10dd2532Schristos     interfaces to retrieve its data.
295*10dd2532Schristos
296*10dd2532Schristos
297*10dd2532Schristos     SVR4-DERIVED PROBLEMS
298*10dd2532Schristos
299*10dd2532Schristos27.  When I run top on my SVR4-derived operating system, it displays all
300*10dd2532Schristos     the system information at the top but does not display any process
301*10dd2532Schristos     information (or only displays process information for my own
302*10dd2532Schristos     processes). Yet when I run it as root, everything works fine. What's
303*10dd2532Schristos     wrong?
304*10dd2532Schristos
305*10dd2532Schristos     Your system probably uses the pseudo file system "/proc", which is by
306*10dd2532Schristos     default only accessible by root. Top needs to be installed setuid
307*10dd2532Schristos     root on such systems if it is going to function correctly for normal
308*10dd2532Schristos     users.
309*10dd2532Schristos
310*10dd2532Schristos
311*10dd2532Schristos     SVR42 PROBLEMS
312*10dd2532Schristos
313*10dd2532Schristos28.  The memory display doesn't work right. Why?
314*10dd2532Schristos
315*10dd2532Schristos     This is a known bug with the svr42 module. The problem has been
316*10dd2532Schristos     traced down to a potential bug in the "mem" driver. The author of the
317*10dd2532Schristos     svr42 module is working on a fix.
318*10dd2532Schristos
319*10dd2532Schristos
320*10dd2532Schristos     STILL STUCK
321*10dd2532Schristos
322*10dd2532Schristos29.  I'm still stuck. To whom do I report problems with top?
323*10dd2532Schristos
324*10dd2532Schristos     The most common problems are caused by top's sensitivity to internal
325*10dd2532Schristos     kernel data structures. So make sure that you are using the right
326*10dd2532Schristos     include files, and make sure that you test out top on the same
327*10dd2532Schristos     machine where you compiled it. Sun's BSD Source Compatability Mode is
328*10dd2532Schristos     also a common culprit. Make sure you aren't using either /usr/ucb/cc
329*10dd2532Schristos     or any of the libraries in /usr/ucblib. Finally, make sure you are
330*10dd2532Schristos     using the correct module. If there does not appear to be one
331*10dd2532Schristos     appropriate for your computer, then top probably will not work on
332*10dd2532Schristos     your system.
333*10dd2532Schristos
334*10dd2532Schristos     If after reading all of this file and checking everything you can you
335*10dd2532Schristos     are still stuck, then please use SourceForge to submit a support
336*10dd2532Schristos     request or a bug. Top is supported by the SourceForge project  named
337*10dd2532Schristos     "unixtop". On SourceForge you will find defect tracking, a mailing
338*10dd2532Schristos     list, and on-line forums. You can also contact the author through
339*10dd2532Schristos     SourceForge.
340*10dd2532Schristos
341