Why is the time messed up on my Ubuntu Server VPS?

A month back loads of services on my VPS stopped working. After messing about for an hour or so i worked out that the time had frozen. I gather it was some sort of virtualization bug and a reboot soon fixed it.

However, today I was trying to run my S3 backup and SSL failed due to the time being wrong. on checking the time i get:

Current default timezone: 'Europe/London'
Local time is now: Sat Jul 11 22:03:02 BST 2009.
Universal Time is now: Sat Jul 11 21:03:02 UTC 2009.

tim@vps:~$ sudo ntpdate ntp.ubuntu.com
11 Jul 22:03:30 ntpdate[3901]: step time server 91.189.94.4 offset -14404.833448 sec

Now im in the UK now and its clearly only just gone 18:03.

I've tried setting the date manually:

sudo date +%T -s "18:03:30"

and when i read it back, it hasnt changed

What have i messed up?

EDIT:

I've run:

tim@vps:/var/log$ sudo hwclock --utc
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
tim@vps:/var/log$ sudo hwclock --localtime
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
tim@vps:/var/log$ sudo hwclock --show
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.

EDIT AGAIN:

I've had it rebooted and its still the same.

also:

tim@vps:~$ sudo hwclock --debug --show
hwclock from util-linux-ng 2.13.1
hwclock: Open of /dev/rtc failed, errno=2: No such file or directory.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.

Solution 1:

Update: I know nothing of xen. But there are a lot of pages out there that discuss your situation.

Here is something I found:

By default, XenVMs have their clocks synchronized to the XenEnterprise Server that hosts them and will ignore requests to adjust the time made by an ntp daemon if one is running. If you want a XenVM to have an independent clock, log on to its Text Console and issue the command

echo 1 > /proc/sys/xen/independent_wallclock

then run an NTP daemon.

To revert to the default, issue the command

echo 0 > /proc/sys/xen/independent_wallclock

Before update: It is probably a virtualization issue. What kind of virtualization software are you using? And what is the time settings on the host?

Solution 2:

The first thing that comes to mind, is what time zone are you configured for?

The second thing that comes to mind has to do with your hardware clock setup - are you using UTC in the hardware, or local time? Most installs recommend using UTC time in hardware and then the system will adjust by time zone, although there are options to do the opposite and have the system and hardware clock both on local time. This can lead to occasional confusion.

For linux, you might try using the hwclock(8) program, which has options to set system time to the hardware clock, and set the hardware clock to the system time. Yeah, you should be able to set the time via the date(1) command, but you're better off using this.

I would also look at using the world-wide NTP pool vs. the vendor's provided pool. You can use it any time by pointing to pool.ntp.org.

Solution 3:

If you're talking about a Xen VPS then generally the clock is managed by the dom0 privileged domain which I would assume the hosting provider would take care of. So long as dom0 has the correct time and/or is running an NTP daemon to keep the system time in sync there shouldn't be a need for any domU to run ntpd itself.

I have several Xen servers in which I only run ntpd on the dom0 and all the domU virtual machines have the correct time. If you are in fact on a Xen VPS I would hazzard a guess that the hosting provider has an issue with the time on the machine itself. I know in most of the documentation for Xen it's actually recommended to zero out the /sbin/hwclock as an empty file as it will cause problems on boot-up if it actually tries to interact directly with the hardware clock because of the virtualization.

Solution 4:

If its a Xen based system you can set independend_wallclock=1 and manage your own time with ntpd.