I compiled ntp for arm My NTP client is not updating the time from any of the server I referred to the post "Why is ntpd not updating the time on my server? (7)" But nothing works out.. Here is the output of ntpq -pn

[Tue May 15 13:18:26 root@Unknown:bin]$./ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================  .INIT.          16 u    -   16    0    0.000    0.000   0.000

I learnt that refid should not be ".INIT" and delay, offset,jitter values should not be 0

On watching the logs for ntpd

[Tue May 15 13:19:08 root@Unknown:bin]$tail -f ntp.log
15 May 12:29:35 ntpd[18175]: proto: precision = 1000.000 usec
15 May 12:29:35 ntpd[18175]: ntp_io: estimated max descriptors: 1024, initial socket boundary:
15 May 12:29:35 ntpd[18175]: Listen and drop on 0 v4wildcard UDP 123
15 May 12:29:35 ntpd[18175]: Listen normally on 1 lo UDP 123
15 May 12:29:35 ntpd[18175]: Listen normally on 2 eth1 UDP 123
15 May 12:29:35 ntpd[18175]: peers refreshed
15 May 12:29:35 ntpd[18175]: Listening on routing socket on fd #19 for interface updates

On a side note -- ntpupdate -u ntp.ubuntu.com works but ntpd doesnt work. My ntp.conf contains just one line

server minpoll 4 maxpoll 4

where above IP is for ntp.ubuntu.com.

[Fri May 18 15:12:26 root@Unknown:~]$ping pool.ntp.org
PING pool.ntp.org ( 56 data bytes
64 bytes from seq=0 ttl=53 time=40.000 ms
64 bytes from seq=1 ttl=53 time=39.000 ms
64 bytes from seq=2 ttl=53 time=39.000 ms
64 bytes from seq=3 ttl=53 time=39.000 ms

Ping works, but server never updates it time

  • What is the output of ip route get Do you have a firewall active? If so - open UDP 123 for incoming traffic from that IP.
    – Nils
    May 15, 2012 at 14:26
  • Could you add the output of iptables -L -n -v to your question? Ike Chris, I'm beginning to suspect firewalling issues.
    – MadHatter
    May 18, 2012 at 11:30

2 Answers 2


Your ntpd believes the remote system is stratum 16 (meaning it has the least reliable time possible). Most ntp clients will not sync with such a system. I highly recommend using pool.ntp.org as described in their directions.

Their example ntp.conf file:

driftfile /var/lib/ntp/ntp.drift

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

Also, you should never use IPs in the configuration file unless your system doesn't support DNS resolution by some crazy twist of requirements.

The NTP Pool project tries to make a semi-intelligent guess as to what time server it should return to you. But you should usually specify the country you want the servers to be from by using the country code in the hostnames. For India it would be:

server 0.in.pool.ntp.org
server 1.in.pool.ntp.org
server 2.in.pool.ntp.org
server 3.in.pool.ntp.org

The same drift, logging, and other options would still apply.

  • 3
    The 0 in the reach column says that your NTP is not able to contact the NTP running on Modify the configuration as suggested by Chris S.
    – marcoc
    May 15, 2012 at 14:02
  • I changed the ntp.conf as suggested
    – Orion
    May 17, 2012 at 12:49
  • It doesnt work still[Thu May 17 17:49:50 root@Unknown:bin]$./ntpq -pn remote refid st t when poll reach delay offset jitter ==================================================================== .INIT. 16 u - 64 0 0.000 0.000 0.000 .INIT. 16 u - 64 0 0.000 0.000 0.000 .INIT. 16 u - 64 0 0.000 0.000 0.000 .INIT. 16 u - 64 0 0.000 0.000 0.000
    – Orion
    May 17, 2012 at 12:55
  • this is what iproute says -- [Thu May 17 17:53:34 root@Unknown:bin]$ip route get via dev eth1 src Dont think its issue with server but there is still something missing, Thanks a lot for response
    – Orion
    May 17, 2012 at 12:57
  • 1
    Try ping pool.ntp.org, sounds like you've got either DNS or Routing issues. Possibly outbound restrictions on your firewall?
    – Chris S
    May 17, 2012 at 13:05

Your system is not getting NTP responses back from the server you have listed, that's what the "INIT" means under the "refid" column: it is still in the INITialization state—sending out packets to get an INITial reading of the time.

Ping may work, but it could be that a firewall is blocking NTP (123/udp) packets between your machine and the one you're trying to reach. Or it may be that your ntp.conf file has a "restrict" line in it that's overly prohibitive, and so even if the packets are getting there and back, they're being ignored. See this previous Server Fault question:

Problem synchronizing server time with ntpd

One way to test if there's a network-level problem with NTP packets is to run "ntpdate {server}" as root to see if that will set the clock locally (NB: ntpd cannot be running when you try this).

If "ntpdate" does not work, it means that something is blocking NTP packets. If "ntpdate" works, but "ntpd" isn't (as the current situation in the question), it means that there's something else in your configuration breaking things.

Remember, just because "ping" to another host works, doesn't mean that the services on that remove host work. It may be that the service/s you're trying to reach are firewalled, or the daemons may not be running on the remote machine. Ping (and traceroute) are simply there to debug IP-level connectivity: they do nothing to test transport-level (TCP, UDP) service availability / reachability.

You must log in to answer this question.

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