Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 works but ntpd doesnt work. My ntp.conf contains just one line

server minpoll 4 maxpoll 4

where above IP is for

[Fri May 18 15:12:26 root@Unknown:~]$ping
PING ( 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

share|improve this question
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 '12 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 '12 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 as described in their directions.

Their example ntp.conf file:

driftfile /var/lib/ntp/ntp.drift


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:


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

share|improve this answer
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 '12 at 14:02
I changed the ntp.conf as suggested –  Orion May 17 '12 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 '12 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 '12 at 12:57
Try ping, sounds like you've got either DNS or Routing issues. Possibly outbound restrictions on your firewall? –  Chris S May 17 '12 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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