1

I'm trying to synchronise my Ubuntu 12.04.5 instance with the Google timeservers at time{1,4}.google.com and I can successfully query using both ntpdate and ntpd but once I start ntp as a service it fails to contact the time servers. Not sure why I'd be able to do one but not the other?

Querying with ntpdate works:

$ ntpdate time1.google.com
14 Feb 10:47:28 ntpdate[17245]: adjust time server 216.239.35.0 offset 0.015588 sec

As does querying with ntpd:

$ ntpd -q -g -c /etc/ntp.conf
ntpd: time slew -0.004094s

But all I see in ntpq once I've started the ntpd service is INIT:

$ service ntp start
$ ntpq -n
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 <local IP>      .INIT.          16 u    -   64    0    0.000    0.000   0.000
 216.239.35.0    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 216.239.35.4    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 216.239.35.8    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 216.239.35.12   .INIT.          16 u    -   64    0    0.000    0.000   0.000

And it doesn't change from this state. My ntp.conf file just consists entirely of the Google servers and nothing else (no restrict lines):

$ cat /etc/ntp.conf
server time1.google.com
server time2.google.com
server time3.google.com
server time4.google.com
WheresWardy
  • 41
  • 1
  • 5
  • What UDP firewalls exist between you and the Internet? Check if the port looks open with a scan: `nmap -sU -p 123 time4.google.com` – John Mahowald Feb 14 '17 at 13:23
  • That's not a particularly optimal configuration (although it should work at a basic level). Some guesses: 1. Your firewall is configured to allow UDP high source ports to UDP 123, but not UDP 123 to UDP 123 2. You're running an AppArmor profile which doesn't allow ntpd to communicate. Check /var/log/syslog & /var/log/kern.log for lines relating to ntpd, and consider running a more lightly-modified version of the default ntp configuration. – Paul Gear Feb 15 '17 at 03:18
  • @PaulGear I've temporarily disabled `ntpd` in AppArmor (and it's no longer shown in the service status for it) but that doesn't seem to have made any difference so I assume having that on hasn't caused the issue (there's no log lines for ntp in those logs, other than for itself starting up, which also doesn't contain anything interesting). Can you explain what you mean by high source ports? What UDP ports does the remote server attempt to communicate back on? – WheresWardy Feb 15 '17 at 10:09
  • I've opened the firewall to allow all traffic on those IPs as well for now and it doesn't seem to be having an impact. – WheresWardy Feb 15 '17 at 10:21
  • I've also recorded the output of the run-once ntpd command to update time, which shows reachability for the remote time servers. I can't understand why they'd work in this scenario but not when running ntpd as a service? https://gist.github.com/WheresWardy/2a55002a177dbb69eca0557ee2c7880f – WheresWardy Feb 15 '17 at 10:24
  • @WheresWardy High source ports means anything between 1024 & 65535. Most SNTP clients use that, whereas most NTP servers just use 123. Depending on the firewall, there might be two different rules for those two (although most would just allow outbound to destination port 123). – Paul Gear Feb 16 '17 at 22:45
  • @WheresWardy It would also be a good idea to turn AppArmor back on and use a configuration with the default restrictions in place (the default configuration on Ubuntu & Debian is pretty good; I use a slightly modified version: http://pastebin.ubuntu.com/24006293/). Otherwise your setup could be abused for DDoS attacks by anything on the same LAN segment. – Paul Gear Feb 16 '17 at 22:48

2 Answers2

0

Come back in 15 minutes and check again.

the client normally takes a few minutes to synchronize to a server.

When started for the first time and a frequency file is not present, the daemon enters a special mode in order to calibrate the frequency. This takes 900 s during which the time is not disciplined.

http://doc.ntp.org/current-stable/debug.html

The debug page also shows a few more variables to look at, notably the associations command.

Community
  • 1
John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • If that were the problem in this case, there would be polls succeeding. But all of the servers are still in init state and the reachability on them is 0. That means no packets are getting through. – Paul Gear Feb 15 '17 at 03:14
0

Managed to resolve this; it was due to the init script hard-coding a different configuration file than the standard one which meant my config file updates were having no effect and the restrict values in the config file it was actually using were incorrect.

WheresWardy
  • 41
  • 1
  • 5