I've recently setup a CentOS 6.x system with NTPD running and am encountering this error when I run ntpq -pn:$ ntpq -pnntpq: read: Connection refusedI know that ntpd is up and functioning via the ntpstat command:$ ntpstatsynchronised to NTP server (204.11.201.12) at stratum 3   time correct to within 71 ms   polling server every 256 sWhy is ntpq -pn not working?
Why does ntpq -pn report Connection refused?
centos;ntp
You can triage this a bit by looking into the output via strace like so:$ strace ntpq -pn ::1|& grep -i connconnect(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) = 0recvfrom(3, 0x7fffc3365a10, 516, 0, 0, 0) = -1 ECONNREFUSED (Connection refused)write(2, Connection refused\n, 19Connection refusedNotice 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) = 0Is NTPD listening on a ipv6 port? $ netstat -taupn|grep udp|grep ntpudp        0      0 10.22.7.237:123             0.0.0.0:*                               24213/ntpdudp        0      0 127.0.0.1:123               0.0.0.0:*                               24213/ntpdudp        0      0 0.0.0.0:123                 0.0.0.0:*                               24213/ntpdSo 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.111Much better. And you can confirm our logic using strace again:$ strace ntpq -pn 127.0.0.1|& grep -i connconnect(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) = 0connect(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.097Referenceshttps://bugs.launchpad.net/fuel/+bug/1469239