7

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.
Tim
  • 199
  • 1
  • 7

7 Answers7

5

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?

Igal Serban
  • 1,575
  • 10
  • 6
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.

Avery Payne
  • 14,536
  • 1
  • 51
  • 88
2

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.

Jeremy Bouse
  • 11,341
  • 2
  • 28
  • 40
2

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

1

try dpkg-reconfigure tzdata to make sure it's set to utc. Also, check you have ntpd installed, and pointed at one of pool.ntp.org's sets of ntp servers.

Cian
  • 5,838
  • 1
  • 28
  • 40
  • Tried that. Setting to BST returns: 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. UTC is just an hour from BST – Tim Jul 11 '09 at 20:37
  • Do you have ntpd installed? What does pgrep ntpd return? – Cian Jul 11 '09 at 20:59
0

I've had issues with this with GoDaddy Virtual Servers. For some reason Virtuozzo (their software) liked to control the time, and it was the incorrect time. I eventually moved to another provider because GoDaddy wouldn't fix their clock.

Adam Brand
  • 6,127
  • 2
  • 30
  • 40
0

My VPS provider has got back to me again and said that there appears to be something wrong on their side (the host machine). So I'll leave it for them to sort out.

UPDATE:

The hosting provider have been on to it and they think its a hardware issue, possibly bios battery. When the host machine boots up the clock is wrong and apparently they cant change the time while its up without locking up all the vm's!

Tim
  • 199
  • 1
  • 7
  • nptd should be able to set the system time independently from the hardware clock's time (As I understand it). – Cian Jul 12 '09 at 01:25