| Wild clock fluctuation within container [message #42887] |
Tue, 14 June 2011 13:32  |
JohnM
Messages: 4
Registered: June 2011
|
Junior Member |
|
|
I'm a customer of a VPS hosting provider that uses OpenVZ, and I've been trying to work with them to sort out a weird problem we've been getting, but they don't seem to be getting anywhere so I'm hoping someone here might be able to help.
Basically, the clock inside my VPS is fluctuating wildly from one minute to the next. I have a cron job which shows this, by writing `date` to a log every minute, and this is what it's showing for the last few minutes:
Tue Jun 14 13:16:01 UTC 2011
Tue Jun 14 13:22:01 UTC 2011
Tue Jun 14 13:23:01 UTC 2011
Tue Jun 14 13:19:01 UTC 2011
Tue Jun 14 13:20:02 UTC 2011
Tue Jun 14 13:21:01 UTC 2011
Tue Jun 14 13:27:01 UTC 2011
Tue Jun 14 13:28:01 UTC 2011
Tue Jun 14 13:24:01 UTC 2011
Tue Jun 14 13:25:01 UTC 2011
Time is jumping backwards and forwards, but always in a number of whole minutes at a time. This was occurring on an Ubuntu VPS, so I ditched that and started with a Debian one, which suddenly developed the exact same problem after a restart. I do not believe that anything I am doing within the container could actually have this effect, as I don't have permission to change the clock. Is this right? Also, another curiosity is that another cron job which calls a Python script each minute shows the correct time, via Python's time.asctime().
The same set of software running on a 'real' physical server, and on an Amazon EC2 instance, show no such problems.
Any ideas, anyone?
|
|
|
|
|
|
|
|
|
|
| Re: Wild clock fluctuation within container [message #42916 is a reply to message #42887] |
Thu, 16 June 2011 14:35  |
JohnM
Messages: 4
Registered: June 2011
|
Junior Member |
|
|
I understand that the kernel has now been updated without solving this problem. On closer inspection of the logs, I have discovered that the clock is not randomly screwy at all - there is in fact a very distinct pattern to it. We have 3 minutes of correct behaviour (e.g, 14:06, 14:07, 14:08), then we leap back in time 4 minutes and have 2 minutes of correct behaviour (14:04, 14:05), followed by a leap forward in time of 6 minutes (to 14:11), whereupon the pattern repeats.
It does suggest to me some rogue behaviour by an ntp daemon or daemons. Is it possible there are 2 (or more) ntp daemons fighting it out over the clock on that node (one in the HW node, one in a container which has, somehow, managed to get clock-altering rights)? And why would this be occurring on such a frequent basis (when the update is normally only once daily).
|
|
|
|
| Re: Wild clock fluctuation within container [message #42917 is a reply to message #42916] |
Thu, 16 June 2011 15:18 |
khorenko
Messages: 533
Registered: January 2006
Location: Moscow, Russia
|
Senior Member |
|
|
Hi,
well, that's strange.
This definitely seems to be the same problem we've already fixed.
Can you please
1) tell the kernel name installed on the node after the update
(you need 91.1 kernel)
2) ask provider if he really updated the kernel (he could just change "uname" output for your CT)
Thank you.
--
Konstantin
If your problem is solved - please, report it!
It's even more important than reporting the problem itself...
|
|
|
|
|
|
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
