In our production box, I am a facing a problem with ntpd. I am enabling the NTP feature for our production box and observing one isssue.

We start the ntpd daemon in the initialization process of our box. During that time internet connection is not there. Below is my small ntp.conf file

driftfile  /etc/ntp.drift
logconfig =syncstatus
server pool.ntp.org iburst

Our box get internet connectivity little late once the interface comes up. That time I see that ntpd does not sync the clock. When I do ntpq -c as , I get no association id's found. I did wait for almost 30 min but still got no association id's found

I have to restart the ntpd. After restarting it, ntpd syncs the clock and everything works normally. But again if I reboot my box then same issue happens. Again I have to restart ntpd, once box comes up and internet is reachable.

Did any one faced similar kind of problem?

Should I delay start of ntpd till the time interface comes up?


I did some more experiment and I replaced server pool.ntp.org iburst with pool pool.ntp.org iburst and with this change ntpd sync the clock automatically. I didn't have to restart the ntpd. So here arises another question to me.

What happened when I replaced server with pool?

Should I always use pool keyword instead of server?

When should I use pool and when should I use server?

I did some research and found that pool is the same as server, except it resolves one name into several addresses and uses them all if they are doing same thing then why server pool.ntp.org iburst didn't worked for me but pool pool.ntp.org iburst worked.


As suggested, I have used pool instead of server but still my clock is not able to synchronize at bootup. Previously no association id's found was coming but after using pool it is displaying the list.

GW:/admin# ntpq -c lpeer
     remote           refid      st t when poll reach   delay    offset  jitter
===================================================================== =========
 time.google.com .POOL.          16 p    -   64    0    0.000   +0.000   0.002

GW:/admin# ntpq -np
      remote           refid      st t when poll reach   delay   offset  jitter

 time.google.com .POOL.          16 p    -   64    0    0.000   +0.000   0.002

GW:/admin# ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
  1 34173  8811   yes  none  none    reject    mobilize  1

GW:/admin# ntpq -c "rv 34173"
associd=34173 status=8811 conf, bcast, sel_reject, 1 event, mobilize,
srcadr=, srcport=0, srchost="time.google.com", dstadr=,
dstport=0, leap=11, stratum=16, precision=-19, rootdelay=0.000,
rootdisp=0.000, refid=POOL, reftime=(no time), rec=(no time), reach=000,
unreach=0, hmode=3, pmode=0, hpoll=6, ppoll=10, headway=0,
flash=1400 peer_dist, peer_unreach, keyid=0, offset=+0.000, delay=0.000,
dispersion=16000.000, jitter=0.002,
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00      0.00    0.00,
filtoffset=   +0.00   +0.00   +0.00   +0.00   +0.00   +0.00   +0.00   +0.00,
filtdisp=   16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

I see flash status as 1400. What is the meaning of 1400 I was not able to found the flash status 1400 in ntp documentation.


It started working. I replaced iburst with minpoll 3 maxpoll 4 and after that it is working on reboot. I used pool like this pool pool.ntp.org minpoll 3 maxpoll 4. I am not sure what difference does this change made.

I also read that we should avoid using minpoll and maxpoll. Too frequent for a sustained period and public NTP services may block you. ntpd is already good at dynamically selecting the pool interval.

Anyway thank you all for helping me.

  • Unless you have a very special reason, you should always use pool instead of server. It has better operational characteristics in almost every way, including the DNS querying behaviour that you've discovered.
    – Paul Gear
    Jul 25, 2021 at 9:45
  • The "special reasons" for using a server line include local hardware reference clocks, authentication using keys, and (optionally) local servers with static ip addresses.
    – user10489
    Jul 25, 2021 at 13:37
  • @user10489 authentication using keys does this mean we can not use pool in authentication? Should it be always server
    – vivek
    Jul 25, 2021 at 14:39
  • At least according to the man page, you cant use a key or autokey directive in a pool line.
    – user10489
    Jul 25, 2021 at 16:03
  • @user10489 Just wondering if we need authentication for the hostname then this become ambiguity. As for hostname resolution, preferred way is to use pool line and for key I can't used pool.
    – vivek
    Jul 25, 2021 at 16:35

1 Answer 1


When you supply a server to ntpd, at startup it resolves the hostname to an ip address and tries to use the ip address to sync the time. If that hostname does not resolve, it deletes it. Even if it does resolve it, it doesn't remember the hostname, only the ip address.

If the server in your server line was a local host with a fixed ip address (rather than a dynamic pool), you could replace the hostname with the real ip address, and it shouldn't delete it even if the network isn't up at startup.

If you supply instead a pool to ntpd, it retains the hostname (and tags it with .POOL.). Periodically (including at startup), it will resolve that hostname in DNS and add any IP's it gets as separate entries, and prune some of the least favorable ones.

You can see some of this with the command ntpq -np or equivalently ntpq -n -c peers

Note that there are also timing issues and ntpd version issues with all of this. This exact problem was filed as a bug in ntpd, and there have been several fix variations. Some versions of ntpd will defer the hostname resolution if it fails, but it may eventually give up anyway; so if you are testing by briefly disconnecting the network and reconnecting it, the problem may not occur. Also, ntp uses a polling algorithm that exponentially increases host poll time for both reachable and unreachable hosts (depending on your clock stability and the usefulness of the host as a time sync) with an upper limit of 1024 seconds (32 minutes), so if network reachability changes, it may take that long for it to notice. (The poll times and intervals are listed in ntpq -np)

Additionally, some boot startup scripts use ntpdate or similar tools to set the system clock to a server from ntp.conf so that the clock is partially synchronized before ntpd starts. This is a one shot attempt, and if it fails, ntpd may start with the clock wildly wrong. If it is only slightly wrong, ntp will fix it, but if it is majorly wrong, ntpd may refuse to sync the clock, and in some cases and versions of ntpd, may crash or exit. Some versions of ntpd have their own one shot clock big step options.

  • I got your point. My question is can we supply ip address to pool or it should always be hostname.
    – vivek
    Jul 24, 2021 at 6:19
  • You can supply an ip address on a server line. It doesn't make any sense to supply an ip address on a pool line.
    – user10489
    Jul 24, 2021 at 6:22
  • I did one small test where i turn off the inteface to cut the internet connectivity. After that I configured server pool.ntp.org iburst and started ntpd. After sometime I brought up the interface and I can see that ntpd is able to sync the clock. So as you said at startup it resolves the hostname to an ip address and tries to use the ip address to sync the time. If that hostname does not resolve, it deletes it doesn't seems to be correct this time.
    – vivek
    Jul 24, 2021 at 8:33
  • There may be timing issues involved as well. I'll add that to the answer.
    – user10489
    Jul 24, 2021 at 12:19

You must log in to answer this question.

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