ntpd doesn't seem to sync at all

Question

I am following this tutorial It's 2008, so I am very careful using its advice. I need to make this machine the master, and let all other machines use it to sync the time. They are all out of sync by 20-30s...

By default the conf file has this:

# Specify one or more NTP servers.

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org

# Use Ubuntu's ntp server as a fallback.
server ntp.ubuntu.com

I just made a slight change and now it becomes server 0.ubuntu.pool.ntp.org iburst.

Restart, and monitor the log

tail -f /var/log/syslog
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen and drop on 1 v6wildcard :: UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 3 eth0 134.74.77.21 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 4 eth1 10.10.0.57 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 5 eth1 fe80::5652:ff:fe5a:f89f UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 6 eth0 fe80::5652:ff:fe01:1aee UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 7 lo ::1 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: peers refreshed
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listening on routing socket on fd #24 for interface updates

It has been 20 minutes and nothing seems to be coming up.... I added other servers but none seems to be working...

ping 0.ubuntu.pool.ntp.org
PING 0.ubuntu.pool.ntp.org (50.7.247.114) 56(84) bytes of data.
From 172.17.200.3 icmp_seq=1 Packet filtered
From 172.17.200.3 icmp_seq=6 Packet filtered

Sounds bad. How about the closest? I am in NY, based on this list of servers

server nist1-ny.ustiming.org iburst

Ping that, also gives me packed filtered.

So what's going on here? Any idea? Thanks.

Here is the actual conf if you need to look at: http://dpaste.org/wDMxO/

---

root@ghive-ldap:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 nist1-ny.ustimi .INIT.          16 u    -   64    0    0.000    0.000   0.000
 name1.glorb.com 128.252.19.1     2 u    -   64    1   32.783   -7.453   0.000
 ns1.oninit.com  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 ns1.your-site.c .INIT.          16 u    -   64    0    0.000    0.000   0.000
 triangle.kansas .INIT.          16 u    -   64    0    0.000    0.000   0.000
 europium.canoni .INIT.          16 u    -   64    0    0.000    0.000   0.000

Answer 1

It appears you are inside network which limits access to ntp servers. Of the six time servers you have specified you are only getting time from one. However, all is not lost.

Try using local time sources. I find reliable NTP sources are common. Often your router and DNS servers will provide a reliable time source. If an dedicated ntp server is available, it is often called ntp or ntp1. If the local domain is example.com then you would find it as ntp.example.com.

For your master server consider using its clock as a time source. Setting is stratum in the range 8 to 12 makes it a useful backup but won't override real sources. This may not be an accurate time source, but can be used as common fallback time source for all your systems. Even if you can't get a good time source, you can at least sync all your systems to the same time source.

# ... and use the local system clock as a reference if all else fails
server  127.127.1.0
fudge   127.127.1.0 stratum 8

It is also possible to use some GPS units as a time source. One of my time sources claims gps as its time source. You can start with the NTP Reference Clocks documentation if you need to use this approach.

Use the command ntpq -p or ntpdc -c peers to check the reliability of your time sources. You can add a hostname to query your peers, although they may be configured not to respond.

You can use ntpdate in debug mode to scan the local network for ntp servers. However, you may find some rouge servers which are highly inaccurate. (One network scan I did found many srtatum 0 servers with clocks that were a day or more off the current date.) Look for a moderately low stratum (2 to 4) with an accurate time. Checking the peers of server at stratums above 3 may help you discover accessible time sources.

Answer 2

ntpdate uses higher number port to send ntp queries. So when port 123 is blocked 'inbound' anywhere between you and ntp server ntpd will fail, but ntpdate will work.