An ubuntu server is running ntp, and connected to the internet. Still, the system clock is about 30 minutes wrong and gets bigger over time.

$ service ntp status
NTP server is running..

Output of ntpq -p

remote           refid      st t when poll reach   delay   offset  jitter

mail.thefrown.n .INIT.          16 u    - 1024    0    0.000    0.000   0.000    .INIT.          16 u    - 1024    0    0.000    0.000   0.000
tshirt.heanet.i .INIT.          16 u    - 1024    0    0.000    0.000   0.000
chilipepper.can .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Which makes it look like a firewall issue? Funny thing is, When I stop ntp and run the following command

ntpdate -u 0.europe.pool.ntp.org
14 Jul 09:27:40 ntpdate[3664]: step time server offset -21.831200 sec

The time DOES get adjusted, which would make me believe that it's not a firewall issue?

  • ntpdate is not ntp. What's in your ntp logs? When did you start ntpd? It takes some time to adjust stratum and so on. Also try with different time providers, like pool.ntp.org
    – Lenniey
    Jul 14 '17 at 9:50
  • Is 0.europe.pool.ntp.org configured in your /etc/ntp.conf? Did you try to ntpdate -u ... the servers that get listed with ntpq -p? Also add iburst on the server line in /etc/ntp.conf.
    – Thomas
    Jul 14 '17 at 10:06
  • 2
    Most likely it is a firewall issue. With the -u option ntpdate uses a random source port, but ntpd always uses the UDP port 123 for client requests. Check if ntpdate without -u works.
    – mlichvar
    Jul 14 '17 at 19:27
  • @mlichvar: That deserves turning into an answer, because it's almost certainly the correct one.
    – Paul Gear
    Jul 14 '17 at 23:57

.INIT. refid actually means the remote is still in an initialized state and has not received packets or pulses yet. It could be network traffic not allowed such as a firewall, but not necessarily.

30 minutes offset is beyond ntpd panic threshold. (Did you mean seconds? The offset in your ntpdate output is only tens of seconds.) Depending on configuration, it may only step the clock once, or refuse and quit. Several operating systems instead call ntpdate first before ntpd.

As mlichvar mentioned, both ntpdate and ntpd may be selecting 123 as the source port.

In addition, ntpdate refuses to adjust when "the NTP socket is in use", which is another reason why ntpd needs to be stopped first. Which is a useful safety mechanism if you do not want the time to be stepped like on a database server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.