CentOS 7 - ntp stuck .INIT

Question

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 ?

Do you have 10.0.0.1 set as your server in ntp.conf on the client machine? — Simon Greenwood, Jan 09 '18 at 13:22
How long are you waiting after ntpd restart before checking it? It will take up to two minutes to get enough packets, given typical minpoll of 64 seconds. — John Mahowald, Jan 09 '18 at 14:17
@JohnMahowald 1 hour and + :( the pool value up, that's all. — user451320, Jan 09 '18 at 15:32
@alias Is this a physical host or a cloud solution? (e.g AWS)? — user3788685, Jan 24 '18 at 15:58
Have you taken a packet capture of ntpdate running vs. ntpd? It would be interesting to compare the packets. — Paul Gear, Feb 16 '18 at 03:57

score 1 · Answer 1 · answered Jan 10 '18 at 14:23

1

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.

answered Jan 10 '18 at 14:23

John Mahowald

32,050
2
19
34

1

I try with iburst without results. I use tcpdump/wireshark to check to and the clients are connecting ... I don't understand why it not work :( – user451320 Jan 12 '18 at 08:29
1

I try to add: * A Debian VM : Sync OK, * A FreeBSD VM : Sync OK But a CentOS - CentOS doesn't work ... I not understand the problem. Also, I have disable selinux for try, no result. – user451320 Jan 12 '18 at 10:09

Evan · Answer 2 · 2018-11-02T17:24:20.537

See if your interface is in the public zone: firewall-cmd --get-active-zones and if not put it there or if yes try adding in your client's ntp.conf:

interface listen 127.0.0.1
interface listen 10.0.0.3 #Put your clients interface address here

Also you may remove ports 123/tcp 123/udp from the public zone since having enabled the ntp service in the zone is enough. The -4 option is also superfluous if you reference your servers' IPv4 address in ntp.conf

CentOS 7 - ntp stuck .INIT

2 Answers2