Check_MK NTP UNKNOWN – no information from NTP: timeout in ntpq -p or NTP daemon not running

by

Would really appreciate some help with this.

I have a remote server that keeps giving me “UNKNOWN – no information from NTP: timeout in ntpq -p or NTP daemon not running” through our Check_MK monitoring.

Other servers in comparison seem to be completely fine.
Aksing Check_MK support and they tell me that this is a server ntp issue and not a monitoring problem.

I know… it’s Friday! So usually this happens a lot through the night and a few times during the day.

my /etc/ntp.conf is…. :

server 213.239.239.164 iburst
server 213.239.239.165 iburst
server 213.239.239.166 iburst

any ideas would be appreciated..

ubuntu 14.04 Physical Server

thanks

Bob

Answer

I just installed an Ubuntu 14.04 VM with exactly the configuration you showed:

root@localhost:~# apt-cache policy ntp
ntp:
  Installed: 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11
  Candidate: 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11
  Version table:
 *** 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11 0
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     1:4.2.6.p5+dfsg-3ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
root@localhost:~# cat /etc/ntp.conf
server 213.239.239.164 iburst
server 213.239.239.165 iburst
server 213.239.239.166 iburst
root@localhost:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*213.239.239.164 192.53.103.103   2 u   26   64    1   15.098   -0.522   0.050
 213.239.239.165 192.53.103.103   2 u   25   64    1   19.043    0.288   0.247
 213.239.239.166 192.53.103.108   2 u   24   64    1   18.900   -1.900   0.206

This is working correctly; it allows ntpq locally and ignores it remotely due to the default restrictions. So my guesses at the cause of your particular issue:

  • old configuration which implements non-default restrictions
  • local firewall on the system in question or on your check-mk monitoring host, possibly involving a full connection tracking table
  • you’ve changed the default apparmor ntpd restrictions in a way that affects its network connectivity
  • high load on the check-mk host, the target host, or the network in between, causing packet loss somewhere along the way

As an aside, using raw IP addresses like that is a great way to end up with non-working NTP somewhere down the track when hetzner decides to change the IP addresses of their NTP servers. Using pool ntp.hetzner.de iburst achieves the same result and is a preferable configuration.

Attribution
Source : Link , Question Author : juliand , Answer Author : Paul Gear

Leave a Comment