Hi,

I've signed up with Linode less than a month ago, and my server has 20 days of uptime since my last migration. When setting up cron yesterday, I've noticed that the clock must have drifted by a whole 1 minute over this time — the clock on my Linode is currently over 1 minute ahead from my other virtual servers elsewhere and from my OS X host.

I've looked at various Linode docs regarding the issue, but it's kinda confusing. There is no /proc/sys/xen on my server, so, according to http://www.linode.com/wiki/index.php/NTP , indeed the clock would not be synchronised.

But why is there no /proc/sys/xen? What's the point of having an independent clock on an average Linode? Is everyone supposed to run their own ntpd, or else accept the inevitable drift? Why was my Linode not setup automatically to have /proc/sys/xen or whatever, so that I won't have to worry about having an independent clock?

Best regards,
Constantine.

That document is many years out of date. With modern kernels (>2.6.20 or so, with Xen support in the mainline kernel), you get the hardware clock with all of its warts, and don't have a /proc/sys/xen.

So, yes, run ntpd. (It should have been installed and configured by default on deployment...)

_________________

/* TODO: need to add signature to posts */

I think it's the difference between the legacy kernels and the paravirt kernels. I don't recall if there was an underlying technical reason or not but the latter are not slaved to the host clock, so you are responsible for managing time in your guest.

-- David

Legacy kernels by default were kept in sync with the host's clock. pv-ops based kernels do not have that option, so you must run ntpd to keep good time.

All of our templates default to pv-ops kernels and have ntpd preinstalled and running by default. It's been that way for some time.

-Chris

All the templates sans the Debian ones? :p

Anyhow, it does seem weird to be running an ntpd on individual Xen nodes, but having a 2 minutes/month drift would be worse...

I've just installed ntp with apt-get, and immediately got the clock shifted back by one minute, from 2011-01-18 16:54 to 16:53 (tcsh history is the proof). Somehow I cannot find the exact amount that the clock was shifted by (nothing relevant in /var/log/ at all, just some useless spam from ntpd in all the log files), but this seems like a bug that `apt-get install ntp` makes a sudden shift of your clock by a minute or so, and doesn't even report the amount by which it was so shifted. Very serious security flaw, even. The ntp package therefore sucks, why are there seemingly no alternatives in Debian? I found neither OpenNTPD nor dntpd in apt.

If the local clock is more than 128 seconds ahead of the reference clock, ntpd will set the clock backwards on start. The -x option will tell it to not to do that, but:

1) You probably will never have this problem again, and
2) It would take about 256,000 seconds (or nearly 3 days) to slew the clock into sync.

This isn't a particularly unique security issue, either; root can set the time as it wants. ntpd will at least set it to a relatively correct time.

And yeah, it does seem weird to run ntpd, but what's between your kernel and the hardware? Very, very little. Artificially synthesizing a more stable frequency source that isn't clocked by an existing hardware oscillator is a bit of a hard problem, too, and the old Xen-patched kernels didn't do a satisfactory job of it.

_________________

/* TODO: need to add signature to posts */

Bah ... a step was indeed missed with the last go at our Debian image. We'll be pushing out the fix tomorrow (and discussing internally how to avoid this in the future). Sorry for the mess.

-Chris

Can electrodes be connected to the ticketing system?

Directly to Jed's ... nose?