reassign 674907 xen found 674907 4.0.1-5.4 notfound 674907 3.2.1-2 severity 674907 grave summary 674907 clock shifts forward by 50 minutes unexplicably under Xen thanks
We have switched to the "ntp" package to see if this was
OpenNTPd-specific: turns out it's not. We are seeing crashes of ntp on
those machines now, and time still shifts by around 50 minutes, so
there's clearly something else going on than a misbehaving NTP client or
server.
So basically, to start from scratch...
Symptoms:
* domU or dom0's clocks shifts forward 50 minutes, around 4 days after
syncing the clock (manually or through ntpd)
* OpenNTPd can't adjust the clock then
* NTP crashes, either before or after the clock shifts
Attempts at solutions:
* using clocksource=jiffies: makes the clock stop or go forward too
fast
* use NTP instead of OpenNTPd (against which this bug was filed
originally): fixes the clock at first, but then looses it again
Possible explanations:
* the clock sync gets lost when NTPd crashes because of some
interoperability issue with xen
* the opposite: NTPd crashes because the clock suddently shifts under
it
Some notes:
* physical servers (not running Xen) using similar hardware and Squeeze
do *not* exhibit similar problems.
* this is a regression from Lenny, which didn't have clock problems
under Xen.
We are going to try and test this under Wheezy to see if the problem can
be reproduced, otherwise this should be tagged "squeeze".
Thanks,
A.
PS: this is marked as grave as it affects other parts of the system and
causes data loss (the time, namely).
--
It is better to sit alone than in company with the bad; and it is better
still to sit with the good than alone. It better to speak to a seeker of
knowledge than to remain silent; but silence is better than idle words.
- Imam Bukhari
pgpMaE94PHGbm.pgp
Description: PGP signature
