Linux ntp not updating

Posted by / 29-Dec-2017 20:21

Yesterday I noticed that the rpi time was wrong (after a short power failure).I started digging and found out that the NTPd service is not updating the local time.This is Cent OS 6.3 x64 on a dedicated server with Intel CPU. The ntpd daemon is still failing, how do I get that to not use privileged ports?) will refuse to (easily) set the time if the offset is too high. Second question, WHY is this machine failing with ntp on privileged ports when all my other servers do not?If we can't find clues from this set of data, tcpdump might be required to see where the packet is being lost.driftfile /var/lib/ntp/ntp.drift statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable server 0.server 1.server 2.server 3.I know NTP doesn't necessarily bring the clock in time immediately. For example, remote refid st t when poll reach delay offset jitter ============================================================================== ns1.1.23 2 u 10 64 1 1.043 0.258 0.001 ns2.62.1 2 u 9 64 1 0.671 0.135 0.001 ns3.62.1 2 u 8 64 1 0.750 0.277 0.001 (We also switched to servers recommenced by the hosting company, but that is beside the point.) The commands in brent's answer were helpful because they made me realise the problem was in network access to the NTP servers, not in NTP configuration itself. The ntpdate command returns something like "17 Dec ntpdate[14195]: no server suitable for synchronization found".$ sudo nmap -s T -s U -p 123 localhost Starting Nmap 6.40 ( at 2015-08-17 EDT Nmap scan report for localhost ( Host is up (0.00013s latency).

No server suitable for synchronization means what it tells, that the communication between client and server cannot be established.

At first I thought maybe a local or network firewall was blocking UDP port 123, but that is not the case- this server can talk UDP port 123 (the ntp protocol) to the Internet and get answers. I tried a dozen other ntp time servers, disabled iptables firewall, and confirmed the datacenter is not filtering udp traffic.

Any ideas what is stopping ntpd and ntpdate from syncing my clock?

but the time never updates, it always stays on the incorrect time (it seems to be pulling time from the ESXi host on reboot unless i set it with ntpdate) I have unticked the box to get the time from the host. 1 u 22 64 377 8.661 -0.036 0.126 -ISP1 2 u 36 64 377 11.720 -0.027 0.280 #PRIVATE7 .

NTPD is running ntpq -pcrv -bash-3.2# ntpq -pcrv remote refid st t when poll reach delay offset jitter ============================================================================== dc3.domai 2 u 29 64 377 0.567 -4263.4 10.392 ass ID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version="ntpd [email protected] Mon Dec 9 UTC 2013 (1)", processor="i686", system="Linux/3.10.23-xxxx-std-ipv6-32", leap=11, stratum=16, precision=-20, rootdelay=0.000, rootdispersion=2356.905, peer=0, refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 .000, poll=6, clock=d81ce655.d5ce975b Mon, Nov 24 2014 .835, state=1, offset=0.000, frequency=-0.140, jitter=0.001, noise=0.001, stability=0.000, tai=0 Something looks to be broken in your time setup.

linux ntp not updating-18linux ntp not updating-65linux ntp not updating-27

Please consider joining the # pool: server 0.iburst server 1.iburst server 2.iburst server 3.iburst # Access control configuration; see /usr/share/doc/ntp-doc/html/for # details. # # Note that "restrict" applies to both servers and clients, so a configuration # that might be intended to block requests from certain clients could also end # up blocking replies from your own upstream servers.