In article <[EMAIL PROTECTED]> Joachim Schrod
<[EMAIL PROTECTED]> writes:
>Per Hedeland wrote:
>> 
>> Browsing the check_ntp.pl Nagios "plugin", which I guess is what is
>> being used here, it seems it obtains the offset from the output of an
>> invocation of *ntpdate* - which begs the question of "ntpdate towards
>> what server?",
>
>Towards the server where the monitored service runs on. Every nagios check is 
>associated to a host, there are no host-independent services.

Which means that in the OP's case, the host where Nagios runs has a ~ 5
second offset from the monitored host, where an essentially well-sync'ed
ntpd is running => The OP needs to get the host where Nagios is running
into shape time-wise. Of course one can question the validity of a
monitoring function whose result is entirely dependent on properties of
the host where *the monitoring function* is running...

>> since ntpdate can't really tell you anything about how
>> your local ntpd is doing (it seems to use ntpq too, but not for the
>> offset).
>
>ntpdate -q localhost
>
>would do that (and might be used, when Nagios monitors localhost).

No it wouldn't - it's just plain bizarre: ntpdate can only tell you the
time offset between the queried host and the local host, which will
obviously always be effectively zero with such a query. We can safely
assume that a 5 second offset was *not* obtained by that command (and
if Nagios actually uses it when monitioring localhost, we can conclude
that Nagios is quite incapable of monitoring the state of NTP in that
case).

--Per Hedeland
[EMAIL PROTECTED]

_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions

Reply via email to