[Nagiosplug-devel] [ nagiosplug-Patches-1159317 ] Patch for check_ntp to work with zero offsets

[SourceForge.net]

Patches item #1159317, was opened at 2005-03-08 11:55
Message generated for change (Comment added) made by wsanders1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1159317&group_id=29880

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: W Sanders (wsanders1)
Assigned to: Ton Voon (tonvoon)
Summary: Patch for check_ntp to work with zero offsets

Initial Comment:
In some (mine) LANS with "perfectly" synchronized
clocks the offset can be zero even though the ntp
daemon is all synced up. "Check_ntp" assumes a zero
offset is an unsynchronized ntpd. The way I got it to
work was to also check for stratum 16, which is also a
sign of zero offset. No need to be paranoid unless you
are sure they are out to get you! Diff -c below:

$ diff -c ../../libexec/check_ntp.0 ../../libexec/check_ntp
*** ../../libexec/check_ntp.0   2005-02-04
13:59:50.000000000 -0800
--- ../../libexec/check_ntp     2005-02-04
14:18:24.000000000 -0800
***************
*** 194,200 ****

                # An offset of 0.000000 with an error
is probably bogus. Actually,
                # it's probably always bogus, but let's
be paranoid here.
!               if ($offset == 0) { undef $offset;}

                $ntpdate_error = defined ($offset) ?
$ERRORS{"OK"} : $ERRORS{"CRITICAL"};
                print "ntperr = $ntpdate_error \n" if
$verbose;
--- 194,200 ----

                # An offset of 0.000000 with an error
is probably bogus. Actually,
                # it's probably always bogus, but let's
be paranoid here.
!               if ($offset == 0 and $stratum == 16) {
undef $offset;}

                $ntpdate_error = defined ($offset) ?
$ERRORS{"OK"} : $ERRORS{"CRITICAL"};
                print "ntperr = $ntpdate_error \n" if
$verbose;


----------------------------------------------------------------------

>Comment By: W Sanders (wsanders1)
Date: 2005-03-08 16:06

Message:
Logged In: YES 
user_id=609888

I don't know if iit would be right to remove the check for 0
offset. When offset is 0 and stratum is 16 this will indeed
usually be accompanied by the "no server suitable for
synchronization" in the ntpdate -q output, which is checked
for in line 204. My logic will still allow the script to
reset $ERRORS to the right value if the string is found in
line 204. I dunno, maybe the case where offset=0 and
stratum=16 and the string is not present never happens.
Still the fact that Ian was being paranoid about it
signifies be probably got burned once or twice by it. I
tried to contact Ian via email and could not find a valid
address for him. 

The "offset" is AFAIK the difference between the system time
and the local NTPD's idea of what the time is supposed to be
based on estimates of delays and stuff in the network. My
particular LAN is highly accurate since I have GPS time
receivers within one or two hops. So on my LAN the offset is
frequently zero since the time sources are very stable and
local and the network delays are very short and consistent. 

"Stratum" is the number of hops (0..15) between the local
ntpd and the authoritative time source. (My stratum is 1
since I directly reference the servers with the GPS
receivers attached.).

The offset rarely stays zero for one than one check - so
with "max_check_attempts" set to more than 1 this will not
result in bogus alarms, the single isolated alerts show up
in the logs and bug PHBs and anal-retentive sysadmins.  HTH...






----------------------------------------------------------------------

Comment By: Ton Voon (tonvoon)
Date: 2005-03-08 14:27

Message:
Logged In: YES 
user_id=664364

I've applied a patch to check_ntp to remove this 0 test, but have to admit 
I'm not exactly sure what is happening here.

Can you say why an offset of 0.000 is good/bad?

----------------------------------------------------------------------

Comment By: Jason Martin (jhmartin)
Date: 2005-03-08 12:44

Message:
Logged In: YES 
user_id=589094

This would probably be better implemented as a command-line
flag with the default behavior remaining as '0 = bad'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1159317&group_id=29880