3

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
==============================================================================
 125.62.193.121  .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 0.0.0.0 UDP 123
15 May 12:29:35 ntpd[18175]: Listen normally on 1 lo 127.0.0.1 UDP 123
15 May 12:29:35 ntpd[18175]: Listen normally on 2 eth1 173.39.19.72 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 91.189.94.4 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 (202.71.140.36): 56 data bytes
64 bytes from 202.71.140.36: seq=0 ttl=53 time=40.000 ms
64 bytes from 202.71.140.36: seq=1 ttl=53 time=39.000 ms
64 bytes from 202.71.140.36: seq=2 ttl=53 time=39.000 ms
64 bytes from 202.71.140.36: seq=3 ttl=53 time=39.000 ms

Ping works, but server never updates it time

MadHatter
  • 79,770
  • 20
  • 184
  • 232
Orion
  • 39
  • 1
  • 1
  • 2
  • What is the output of `ip route get 125.62.193.121`? 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 Answers2

6

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.

Update:
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.

Chris S
  • 77,945
  • 11
  • 124
  • 216
  • 3
    The `0` in the `reach` column says that your NTP is not able to contact the NTP running on `125.62.193.121`. 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 ==================================================================== 202.71.136.67 .INIT. 16 u - 64 0 0.000 0.000 0.000 119.226.101.131 .INIT. 16 u - 64 0 0.000 0.000 0.000 122.166.117.103 .INIT. 16 u - 64 0 0.000 0.000 0.000 123.108.200.163 .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 125.62.193.121 125.62.193.121 via 173.39.18.1 dev eth1 src 173.39.19.72.. Dont think its issue with server but there is still something missing, Thanks a lot for response – Orion May 17 '12 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 '12 at 13:05
  • Looks like DNS, Routing, and Firewall (at for ICMP) aren't issues. Sorry if this is obvious, but you waited a few minutes before checking `ntpq` as `ntpd` takes a minute or three to connect... – Chris S May 18 '12 at 13:48
  • Yes I waited more than an hour to do so. One other thing in mind was does ntp utility requires some help from OS in which it is working? Could it be that my OS is missing some API's that ntp uses? Also is there a way I can check if my port 123 is fully functional and dont obstruct any traffic? thanks for all the response – Orion May 20 '12 at 18:16
  • `ntpd` doesn't need any special APIs for basic functionality, which is what it starts with. It does for "smoother" clock corrections, but that's all long run stuff. Try running `ntpdate -qu 0.in.pool.ntp.org` and see what it returns. It's possible your ISP is doing something really dumb, especially considering your country (no offense intended, ISPs on your side of the marble tend to be very backwards with alarming regularity). – Chris S May 21 '12 at 01:28
2

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.

Community
  • 1
DAM
  • 21
  • 1