ntp check is worse than useless

[James Troup]

Binary package hint: nagios-plugins

james@lutetium:~$ /usr/lib/nagios/plugins/check_ntp -H 127.0.0.1
NTP OK: Offset nan secs|offset=nan
james@lutetium:~$ ntpq -p
ntpq: read: Connection refused
james@lutetium:~$ ps auxfww | grep ntp
james 20369 0.0 0.2 3900 800 pts/2 S+ 10:34 0:00 \_ grep ntp
james@lutetium:~$

Err. NTP not running is not 'OK'.

[Adam Buchbinder (adam-buchbinder)]

I can't reproduce this on my desktop machine or on my nagios server.

$ /usr/lib/nagios/plugins/check_ntp -V
check_ntp (nagios-plugins 1.4.5) 1.11
$ /usr/lib/nagios/plugins/check_ntp -H 127.0.0.1
NTP CRITICAL: No response from NTP server

$ ./check_ntp -V
check_ntp v1861 (nagios-plugins 1.4.11)
$ ./check_ntp -H 127.0.0.1
NTP CRITICAL: No response from NTP server

What version are you running (check_ntp -V)? (And what does "ntpdate -ud 127.0.0.1" show when you run it? If you don't have a running NTP server, it should say "127.0.0.1: Server dropped: no data" somewhere in its output.)

Also, the newer versions of nagios-plugins (in Hardy or later) are supposed to use check_ntp_peer (for seeing if an NTP server is up) and check_ntp_time (for seeing if the server's time is accurate); check_ntp is currently deprecated.

[Mackenzie Morgan (maco.m)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[James Troup (elmo)]

> I can't reproduce this on my desktop machine or on my nagios server.

I can; with up-to-date hardy:

# /usr/lib/nagios/plugins/check_ntp -H 127.0.0.1; echo $?
NTP OK: Offset unknown|
0
# ntpq -p
No association ID's returned
#

> What version are you running (check_ntp -V)?

# /usr/lib/nagios/plugins/check_ntp -V
check_ntp v1861 (nagios-plugins 1.4.11)
#

> (And what does "ntpdate -ud 127.0.0.1" show when you run it? If you
> don't have a running NTP server, it should say "127.0.0.1: Server
> dropped: no data" somewhere in its output.)

# ntpdate -ud 127.0.0.1
 3 Oct 17:17:56 ntpdate[28773]: ntpdate 4.2.4p4@1.1520-o Fri Mar 7 20:36:59 UTC 2008 (1)

[...]

 3 Oct 17:17:56 ntpdate[28773]: no server suitable for synchronization found
#

> Also, the newer versions of nagios-plugins (in Hardy or later) are
> supposed to use check_ntp_peer (for seeing if an NTP server is up)
> and check_ntp_time (for seeing if the server's time is accurate);
> check_ntp is currently deprecated.

If it's deprecated and broken (which it is), surely it should be
removed?

[Thierry Carrez (ttx)]

When NTP is not running we currently get:
$ /usr/lib/nagios/plugins/check_ntp -H 127.0.0.1; echo $?
NTP CRITICAL: No response from NTP server
2

However, I can reproduce James' case :
- install nagios-plugins and ntp
- edit /etc/ntp.conf to comment out the "server" line and restart ntp
"ntpq -p" should then return "No association ID's returned" : the NTP server is running, but not fully configured.

Then you get:
$ /usr/lib/nagios/plugins/check_ntp -H 127.0.0.1; echo $?
NTP OK: Offset unknown|
0

Without any parameter, ntp_check just checks that a NTP server is running. To have it react to bad offsets (or the absence of) then you should provide -c / -w parameters... I agree that's questionable design, but probably still a feature and not a bug ?

[Thomas Guyot-Sionnest (dermoth)]

This was a feature since check_ntp had multiple possible possible thresholds (-w/-c, -j/-k). Without any threshold specified it was not checking anything besides receiving a response.

check_ntp_* does return critical on these cases and check_ntp is deprecated and its behavior will not change.

[Thomas Guyot-Sionnest (dermoth)]

Marking Invalid because:

1. No thresholds were specified - specifying some kind of thresholds would actually cause it to monitor properly.
2. Check_ntp is deprecated and both replacement plugins, check_ntp_peer and check_ntp_time, should not show this weird behaviour.