NTP CRITICAL: Offset unknown

[jbennett]

I highly doubt that we are using an atomic clock.

Let me get with the networking team and see if they can get me that information. I'm going to assume that this is an issue with the NTP server not being configured correctly.

[abrist]

Great, let us know. Just FYI, most ntpd servers are set up as statum=1 or higher.

[jbennett]

Apparently, stratum is not set to 0 on the NTP server.

If I'm running this check with '-H localhost', it should be comparing the NTP time on the localhost against the NTP server that's configured in /etc/ntp.cfg, correct?

I'm assuming that the stratum on the localhost is set to 16 per the following:

Code: Select all

# ntptrace
localhost: stratum 16, offset 0.000000, synch distance 0.002355

[abrist]

If I'm running this check with '-H localhost', it should be comparing the NTP time on the localhost against the NTP server that's configured in /etc/ntp.cfg, correct?

Correct.

I'm assuming that the stratum on the localhost is set to 16 per the following:

Also Correct.

It is interesting that the previous command I had you run did not list a stratum 0 server when the plugin does:

Code: Select all

ntpdc -p

There may still be a bug . . . ?

[jbennett]

I think I've figured it out, and I feel pretty stupid for not catching this until now.

I was under the impression that I wanted to check the localhost AGAINST timeserver1, thus the reason I was using -H localhost.

Apparently, this is wrong for this plug-in.

It needs to be -H <NTP server>

Once I did this, things look correct now.

The help file even shows this:

Code: Select all

Examples:
  ./check_ntp_time -H ntpserv -w 0.5 -c 1

[abrist]

No worries, I am just glad your issue is resolved and that I don't have to bug our plugin devs with a . . .bug. Cheers.