5

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?

5
  • Is this in a virtual machine? I suspect that the internal clock is drifting.
    – TheCompWiz
    Jan 5, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 12:10

2 Answers 2

1

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.

1
  • 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, 2012 at 11:31
0

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.

You must log in to answer this question.

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