Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a strange issue I'm starting to troubleshoot and wondered if anyone would have any helpful tips.

I have a cronjob executed every minute that executes a script and appends the output to a file on a filer. The job prints the current timestamp since epoch (date +%s) and the current uptime uptime (including the current system time) to a file.

The script is:

DATE=`date +%s`
UPTIME=`uptime`
echo "$DATE;$UPTIME"

And what I get is:

1325770921; 14:42:01 up 17 days
1325775379; 14:43:01 up 17 days
1325771041; 14:44:01 up 17 days

Notice how the timestamp in the middle is ~1 hour 15 minutes off.. any ideas as to the cause?

share|improve this question
    
Is this in a virtual machine? I suspect that the internal clock is drifting. –  TheCompWiz Jan 5 '12 at 16:15
1  
I ask... because "uptime" is measured using the hardware clock's initial time (on boot) and then subtracting the current hardware clock's time. The Date algorithm is based on clock-cycles... (which is very odd... I know) ... and in virtual machines especially... this can drift as a fixed number of cycles doesn't take a constant amount of time anymore. –  TheCompWiz Jan 5 '12 at 16:32
    
Has this happened more than once or is that a one-off glitch? If it has happened before, is it regular or irregular? –  Ladadadada Jan 5 '12 at 16:59
    
Thanks guys! Yes this is a VM and yes it's happening quite frequently but not with any precise frequency that I'd be able to notice. The interesting thing is that if you look at the data above - the third timestamp is spot on - it's just as if the second one jumps into the future but then a minute later we're back on track - are there any clock correction mechanisms that might be fixing things once they drift off? –  RnR Jan 5 '12 at 20:17
    
VM management systems usually have their own methods for keeping the time correct in the VMs. Here's somewhere to start for VMWare. –  Ladadadada Jan 6 '12 at 12:10
add comment

2 Answers

You mention in the comments that you are running a virtual machine. Virtual machines should have an NTP client running continually correcting for the proper time and date. If you don't do this, the interaction between the physical hardware clock and the virtual clock can get messy and the time will drift.

Really, every system should run NTP, but in virtual machines it is critical instead of just recommended.

Linux and BSD environments should have both NTPd and OpenNTPd available; you didn't mention which environment you are using.

share|improve this answer
    
We are running NTP afaik - notice the time goes back "exactly" to where it should be - to be true I wonder if it isn't some race condition between NTP and my cronjob - maybe adding a sleep to the job would solve this - I'll give it a try. –  RnR Jan 12 '12 at 11:31
add comment

Depending on your VM it could be that your Guest clock is tied to the hosts.

Please check

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

See http://wiki.debian.org/Xen after heading 'clocksource/0: Time went backwards'. It's gives you some workaround to try if you happen to on a Xen VM.

We've had some funny time jumping with these and depending on how old your dom0 is and how new your domU guests are we've had to use xen and jiffies to make the time behave and to be able to really use ntp on guests.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.