Why does ntpq -pn report "Connection refused"?
You can triage this a bit by looking into the output via strace like so:
$ strace ntpq -pn ::1|& grep -i conn
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_INET6, sin6_port=htons(123), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
recvfrom(3, 0x7fffc3365a10, 516, 0, 0, 0) = -1 ECONNREFUSED (Connection refused)
write(2, "Connection refused\n", 19Connection refused
Notice that it's using ipv6 to connect. Basically this line:
connect(3, {sa_family=AF_INET6, sin6_port=htons(123), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
Is NTPD listening on a ipv6 port?
$ netstat -taupn|grep udp|grep ntp
udp 0 0 10.22.7.237:123 0.0.0.0:* 24213/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 24213/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 24213/ntpd
So it doesn't appear to be listening on ipv6, hence the error. We can work around this by telling ntpq -pn to connect explicitly on ipv4 instead like so:
$ ntpq -pn 127.0.0.1
remote refid st t when poll reach delay offset jitter
==============================================================================
+69.89.207.199 212.215.1.157 2 u 209 256 377 43.582 2.768 0.076
-72.5.72.15 10.3.255.0 3 u 217 256 377 68.627 -1.833 4.388
*204.11.201.12 66.220.9.122 2 u 244 256 377 61.928 -0.712 0.234
+108.59.2.24 130.133.1.10 2 u 178 256 377 1.824 3.256 0.111
Much better. And you can confirm our logic using strace again:
$ strace ntpq -pn 127.0.0.1|& grep -i conn
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
Notice that ipv4 uses sa_family=AF_INET whereas ipv6 uses sa_family=AF_INET6 when the ntpq client attempts to connect to your ntpd via UDP on port 123.
We can also use the -4 and -6 switches to ntpq -pn as well:
$ ntpq -pn -4
remote refid st t when poll reach delay offset jitter
==============================================================================
+69.89.207.199 212.215.1.157 2 u 235 256 377 43.582 2.768 0.047
-72.5.72.15 10.3.255.0 3 u 248 256 377 68.627 -1.833 4.417
*204.11.201.12 66.220.9.122 2 u 265 256 377 61.802 -0.765 0.198
+108.59.2.24 130.133.1.10 2 u 212 256 377 1.824 3.256 0.097
References
- https://bugs.launchpad.net/fuel/+bug/1469239
I had the same issue recently with CentOS7. ntpq -p would show 'read: Connection refused', as well as many other commands in ntp debug such as 'clocklist' and some others. NTP servers I set in ntp.conf were being ignored. Here are some other notable outputs:
[root@server ~]# ntpstat
synchronised to NTP server (69.164.198.192) at stratum 3
time correct to within 56 ms
polling server every 1024 s
[root@server ~]# ntpdate
14 Oct 00:02:14 ntpdate[21443]: no servers can be used, exiting
[root@server ~]# systemctl status ntp
Unit ntp.service could not be found.
[root@server ~]# systemctl status ntpd
ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)
Active: inactive (dead)
ntpq> version
ntpq [email protected] Thu Aug 8 11:48:03 UTC 2019 (1)
ntpq> clocklist
ntpq: read: Connection refused
ntpq> cooked
Output set to cooked
ntpq> readlist
ntpq: read: Connection refused
When I checked the IP of the NTP server it was using, it was always something from ARIN(?) or a big provider like Level3. I couldn't choose the server, but the servers it was using looked OK. But it still would not let me choose my own servers no matter what I did in /etc/ntp.conf.
I began to suspect I had a bad program somehow, and I started to suspect the epel repository I loaded as I needed some other programs from there.
Sure enough, I performed the following and resolved the issue:
yum remove ntp
yum install ntp --disablerepo=epel
It reinstalled, now ntpq -p works, and systemctl status ntpd appears as:
[root@server ntpstats]# systemctl status ntpd
● ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled)
Active: active (running) since Mon 2019-10-14 22:14:44 CDT; 3s ago
Finally the servers I set in /etc/ntp.conf are being used.
I don't know how to get word to epel that their CentOS7 ntp is somehow hosed, maybe someone will see this and report.
Note that both epel and the CentOS repository were showing the same version: ntp-4.2.6p5-29.el7.centos.x86_64.