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