CentOS 7 – ntp stuck .INIT

centos7ntpntpdrhel7

I've two ntp servers with one client server.

NTP servers are sync time OK.
The client stuck on .INIT. step but sync manually works.
The client ping and have allowed policies with NTP servers.
Alls machines are in CentOS 7 version.

Firewallinng :

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh ntp
  ports: 443/tcp 123/tcp 123/udp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Display ntp client state :

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.0.0.1    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.0.0.2    .INIT.          16 u    -   64    0    0.000    0.000   0.000

Try :

# ntpdate -d -d -d -d 10.0.0.1
 9 Jan 13:38:30 ntpdate[17833]: ntpdate 4.2.6p5@1.2349-o Wed Apr 12 21:24:06 UTC 2017 (1)
Looking for host 10.0.0.1 and service ntp
host found : 10.0.0.1
transmit(10.0.0.1)
transmit to 10.0.0.1
receive(10.0.0.1)
offset: 0.063550, delay 0.00024
transmit(10.0.0.1)
transmit to 10.0.0.1
receive(10.0.0.1)
offset: 0.063537, delay 0.00027
transmit(10.0.0.1)
transmit to 10.0.0.1
receive(10.0.0.1)
offset: 0.063543, delay 0.00034
transmit(10.0.0.1)
transmit to 10.0.0.1
receive(10.0.0.1)
offset: 0.063526, delay 0.00023
server 10.0.0.1, port 123
stratum 3, precision -23, leap 00, trust 000
refid [10.0.0.1], delay 0.02585, dispersion 0.00000
transmitted 4, in filter 4
reference time:    ddff34f7.aeaac96d  Tue, Jan  9 2018 13:32:55.682
originate timestamp: ddff364c.fb3327e5  Tue, Jan  9 2018 13:38:36.981
transmit timestamp:  ddff364c.eae5727e  Tue, Jan  9 2018 13:38:36.917
filter delay:  0.02586  0.02589  0.02596  0.02585
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.063550 0.063537 0.063543 0.063526
         0.000000 0.000000 0.000000 0.000000
delay 0.02585, dispersion 0.00000
offset 0.063526

 9 Jan 13:38:36 ntpdate[17833]: adjust time server 10.0.0.1 offset 0.063526 sec

It's OK

Second try :

# ntpdate -u 10.0.0.1
 9 Jan 13:39:38 ntpdate[17836]: adjust time server 10.0.0.1 offset 0.063340 sec

It's OK

I find a RHEL topic with IPv4/IPv6 problems :
https://access.redhat.com/solutions/462573

I add "-4" parameter to ntpd file :

# cat /etc/sysconfig/ntpd
# Command line options for ntpd
OPTIONS="-g -4"

I retry full test and the result are the same.

I check the status service :

# systemctl status ntpd
? ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)
   Active: active (running) since mar. 2018-01-09 13:40:21 CET; 3s ago
  Process: 17863 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 17864 (ntpd)
   CGroup: /system.slice/ntpd.service
           +-17864 /usr/sbin/ntpd -u ntp:ntp -g -4

janv. 09 13:40:21 client_server systemd[1]: Starting Network Time Service...
janv. 09 13:40:21 client_server systemd[1]: Started Network Time Service.
janv. 09 13:40:21 client_server ntpd[17864]: proto: precision = 0.130 usec
janv. 09 13:40:21 client_server ntpd[17864]: 0.0.0.0 c01d 0d kern kernel time sync enabled

I can't seen any problems … But with ntpq -p, NTP stuck on .INIT. step.

Someone have an idea please ?

Best Answer

You may append iburst to server lines of your NTP servers to speed up initial sync. (The burst of NTP packets is considered impolite on public NTP resources, but a single burst is very little load.)

Also, try a packet capture on the server to confirm the clients are connecting. Wireshark has a dissector to get the time stamps out of the packets.