Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After 3 days uptime, I can't run top in Linux.

This is x86 Linux Fedora Core 8 running under vmWare under Windows XP.

[root@fc8 ]# uname -a
Linux fc8 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 i386 GNU/Linux

ps, uptime works fine.

Anyone have any suggestion on what might be the problem or how to diagnose it?

Updates:
There is no error message. The "top" command just hangs there.

Also, one other problem I notice at the sametime was that time somecommand gives:

real    0m0.000s
user    0m0.000s
sys     0m0.000s

The somecommand did take a few seconds to execute.

The system time in Linux under vmWare session is corrected. I don't use the ntp to sync time. I have a cron job to sync time with the hwclock --hwtosys command.

share|improve this question

migrated from stackoverflow.com Dec 3 '09 at 17:26

This question came from our site for professional and enthusiast programmers.

1  
I think you might be more likely to find your answer at SuperUser.com – DOK Dec 3 '09 at 17:09
1  
When you go there, be sure to bring with you the error message you're getting, or any information at all as to what actually happens. – qid Dec 3 '09 at 17:11
1  
superuser.com if it's just your personal machine, serverfault.com if it's server (and since it has few days uptime it's probably server) – Phil Dec 3 '09 at 17:15
1  
try running "strace top" to see where top is getting stuck. It may give you some clues. – camh Jan 5 '10 at 8:36

What is the VM's clock showing at these times? It could be something strange in what-ever combination of clock syncing (if any) is going on. If VMWare is slowing the VM's clock a lot to try account for what it thinks is the VM's time getting to far ahead then that might explain time returning a wall-clock time of 0 and top (which takes some readings, waits a second or so, takes some more readings, then updates its display) pausing waiting for the second(s) to tick over.

If the clock does seem to be where is shouldn't be: I find the most reliable way to keep VM clocks accurate is to make sure VMWare's clock sync options are off and use NTP with tinker panic 0 at the top of the config file.

share|improve this answer
    
David, I use this to sync time instead of ntp. I notice the hwclock in Linux always provide the right time. I have issue with company firewall blocking the NTP. [root@fc8 pogo]# crontab -l # hourly to sync the hwclock 0-59 * * * * /sbin/hwclock --hctosys # Work day sync of NTP server at 11 am * 11 * * 1,2,3,4,5 /usr/sbin/ntpdate 10.81.24.191 – tony-p-lee Dec 3 '09 at 20:07
    
The time in Linux under vmWare is correct. – tony-p-lee Dec 3 '09 at 20:07

Question: Did you use a newly woken up vmware session? I noticed that the clock sometimes only restores to the correct time after something like a minute, although it feels a lot longer :-(. Did you check your (ntp?) time-service?

share|improve this answer

You could try installing and using htop - http://htop.sourceforge.net/

How log did you leave top sitting there? Did you give it 10 minutes, for example?

share|improve this answer
    
This time, I reboot the system. Previously, I have seen it hanged there for at lease a few hours. Reboot Linux in vmWare does solve the problem. – tony-p-lee Dec 4 '09 at 6:58
    
Just did a yum install htop, it is very nice. BTW, I might be able to use strace to track down deeper, will try that when I see it happen again. Thanks for suggestion and inspiration... – tony-p-lee Dec 4 '09 at 7:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .