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
Improve this question
7
  • 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
    Commented Feb 14, 2017 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
    Commented Feb 15, 2017 at 3: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
    Commented Feb 15, 2017 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
    Commented Feb 15, 2017 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? gist.github.com/WheresWardy/2a55002a177dbb69eca0557ee2c7880f
    – WheresWardy
    Commented Feb 15, 2017 at 10:24

2 Answers 2

Reset to default
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.

Improve this answer
1
  • 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
    Commented Feb 15, 2017 at 3: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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .