Ubuntu's clock is off by about a half hour:
Where do I even start troubleshooting this?
It's allegedly being set "automatically from the Internet". How can I verify that "the Internet" knows what time it is?
Details
Ubuntu has had plenty of time to communicate with the Internet:
$ date; uptime
Fri May 18 05:56:00 PDT 2012
05:56:00 up 12 days, 10:48, 2 users, load average: 0.61, 0.96, 1.15
This time server I found via a web search does appear to know the correct time:
$ date; ntpdate -q north-america.pool.ntp.org
Fri May 18 05:56:09 PDT 2012
server 208.38.65.37, stratum 2, offset 1752.625337, delay 0.10558
server 46.166.138.172, stratum 2, offset 1752.648597, delay 0.10629
server 205.189.158.228, stratum 3, offset 1752.672466, delay 0.11829
18 May 05:56:18 ntpdate[29752]: step time server 208.38.65.37 offset 1752.625337 sec
There aren't any reported errors related to NTP:
$ grep -ic ntp /var/log/syslog
0
After rebooting, the time was automatically corrected and the following appeared in /var/log/syslog:
May 18 17:58:12 aux ntpdate[1891]: step time server 91.189.94.4 offset 1838.497277 sec
A log of the offset reported by ntpdate reveals that the clock is drifting by about 9 seconds every hour:
$ while true; do ntpdate-debian -q | tail -n 1 >> 'drift.log'; sleep 16m; done
^C
$ r -e '
attach(read.table("drift.log", header=FALSE))
clock <- as.POSIXct(paste(V1, V2, V3), format="%d %b %H:%M:%S")
fit <- lm(V10~clock)
png("drift.png")
plot(clock, V10, xlab="Clock time", ylab="Time server offset (s)")
abline(fit)
mtext(sprintf("Drift rate: %.2f s/hr", fit$coefficients[[2]]*3600))
'
ntp does well at keeping your computer set to the right time, and does that without ever running it backwards--which would be a bad thing for some programs you might be running.
It not only sets the time, but it makes continuous adjustments to how your computer keeps time so that its time is not only right at one instant in time, but stays close to the real time (within dozens of milliseconds, not dozens of minutes). It adjusts both phase (the time) and rate (how fast the clock "ticks"). ntp never makes the clock run backwards. It can take a long time to establish how fast to tick the clock after a reboot, so ntp keeps track of the drift in a file called /var/lib/ntp/ntp.drift . Since you aren't running ntp none of this happens.
ntp is not as popular as it once was because sleeping laptops and desktops, and virtual machines stop it from running some of the time. It's designed to run every once in a while on its own schedule on a computer that is running all of the time, and in the real world where time is continuous. That's probably why it isn't installed by default on the modern workstation. [For Vmware, see this]
Instead ntpdate is run when the network interface is brought up. When a sleeping laptop is awakened it reestablishes the network connection, ntpdate is run, and the time is again correct. If the machine's hardware clock is pretty accurate, and the network is brought up and down fairly often, that's generally good enough for most people.
For some reason stock ntpdate doesn't alway run. Use ntpdate-debian instead in this case. Syntax for the for.mer is something like ntpdate ntp.ubuntu.com, for the latter it is ntpdate-debian
In the absence of one of those things, then ntp is a better way to keep time.
Systems are designed to take a timer interrupt every so often and update its idea of the time every interrupt. As long as the hardware timer is running to spec. the time doesn't drift too much. If the hardware timer isn't, the time will drift more (all such clocks will drift some, for the same reason your wristwatch or battery controlled clock will. Clocks plugged into the wall are synced to the time by the frequency and phase kept by your power company).
Most computer timers are controlled by a crystal controlled oscillator circuit on its integrated circuits. Despite the crystal, they run faster and slower depending on the environment, mostly the temperature. Unless you have some time syncing software installed we don't know about, I'd say your system's clock is off spec.
If you were to run ntp for a day or two it would store information in /var/lib/ntp/ntp.drift that would indicate how much it would have to adjust the rate at which your operating system time advances per interrupt in order to match your hardware clock rate with the real time it gets over the internet. Keeping the file the same and just starting and stopping ntp after a minute after that (assuming you keep the /var/lib/ntp/ntp.drift file unchanged) might do a lot to correct for this if the clock bias ntp sets remains after ntp ends. I'm not sure of this detail.
I suspect the value ntp would store in /var/lib/ntp/ntp.drift is far different than mine.
If this machine is kept running all of the time, however, the best thing to do is to install ntp and let it do its thing. See the other answers for details on getting the time right before starting it. I run ntp on my desktop and ntpdate on my laptop.
An interesting possible alternative, adjtimex, is mentioned in this answer by nealmcb.
If your system is not kept running all of the time, running ntpdate at boot time seems like a good option.
Warning some software can freak if the computers time goes backwards. Running ntpdate after boot could cause this to occur.
One gotcha, that can be a problem: As I recall ntp expects the time to not be too far off. If it is, trying to act conservatively, ntp won't adjust the time at all. If you are in this situation it makes sense to do both--run ntpdate at boot to get the time initialized to the right time, and then let the ntp run to keep it running to provide accurate timekeeping. In particular a bad motherboard battery can cause this error, as can booting a computer that's been off for a long time.
- Usually time is only synced once upon each boot or wakeup-from-sleep
No, Ubuntu's time server is correct, and it is setting the time automatically from it.
The problem is that is usually occurs only once upon each bootup (or to be more precise, each time a network interface is brought up - whether from shutdown, sleep or hibernation). Based on your uptime, it's safe to say it wasn't sync'd in more than a week. And your system clock is running slightly fast for some reason.
- Set up an hourly
cronjob to sync if you don't reboot often, or your server/desktop never goes to sleepYour best bet is to set up a cron-job, I'd say hourly if you want super-precise time. The easiest way to do that is:
sudo editor /etc/cron.hourly/ntpsyncAdd the following lines:
sudo chmod +x /etc/cron.hourly/ntpsyncYou can put this in
/etc/cron.dailyinstead if you would like, for once per day.This can happen if you have installed the ntp time daemon and the time on you machine is too far off to correct quickly.
To fix it open a terminal and do
What this does:
If you don't have ntp installed, do it with
Update: Using ntpdate in a cron job, as has been recommended here, leads to subtle problems.
The ntpdate will make the time 'jump' every hour or so. Using ntp avoids this problem, because it will adjust time by skewing the clock. Also, while selecting an ntp server in the neighborhood gives even higher accuracy, it's not necessary. The default ntp config file has several servers in it and the server automatically compensates for any delays.
Bottom line: - use ntp - if you are far of, shutdown ntp, run ntpdate once and restart ntp.
I had a similar problem and it was caused by something in the firewall. In the end I added the hourly cron job but added the
-uargument tontpdateto get it to use a none standard port.My problem was caused by Ubuntu not actually checking if
ntpdateworked but automatically assuming that it would work.