0

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

Paul Gear
  • 4,367
  • 19
  • 38
juliand
  • 11
  • 2
  • might not be the brilliant solution, but can you ping those IPs from your server, and what is the response time? and do you have the same config on the other servers? – htm11h Jul 07 '17 at 15:02
  • Is that your entire /etc/ntp.conf? If so, and you're up-to-date with the Ubuntu ntp package, it should work when queried locally, but should refuse connections remotely due to the default restrictions. – Paul Gear Jul 09 '17 at 12:32

2 Answers2

0

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.

Paul Gear
  • 4,367
  • 19
  • 38
  • Hi Paul, Thanks for you answer.. - old config - What old config do you mean? - local firewall .. There is no limitation between the server and the check_mk host. - apparmor - As far as i know we do not use apparmor at all - High load -- Yes .. This seems the most likely reason for this problem.. How can I modify either the check_mk check or the ntp check so that this does not occur? – juliand Jul 11 '17 at 06:12
  • If your server was upgraded from a previous version of Ubuntu with a previous version of ntpd, you may not have updated /etc/ntp.conf to reflect the new version. Putting your entire configuration in a pastebin or your question would help to clear this up. AppArmor is enabled by default on Ubuntu; worth checking. But given your explanation, it seems most likely that your check_mk host is trying to run ntpq against your NTP server, which won't work unless you explicitly allow it with a restrict clause. – Paul Gear Jul 12 '17 at 07:56
0

This error actually stopped when I installed the update Check_MK agent 1.4 over the version 1.2. This I did yesterday and since then have received no ntp unknown messages from Check_MK for this server.

Thank you very much for your very detailed answer.

bob

juliand
  • 11
  • 2