<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000099">
I encountered this too. My solution was a script in /usr/local/scripts
called by cron that stops the NTP daemon, runs "ntpdate
<local_server>" twice, then restarts the NTP daemon. This runs in
cron every 2 hours and seems to keep things in sync...<br>
<pre class="moz-signature" cols="72">
  A. Davis
  Email:     <a class="moz-txt-link-abbreviated" href="mailto:nccomp@gmail.com">nccomp@gmail.com</a>

  "There is no limit to what a man can accomplish
   if he doesn't care who gets the credit." - Ronald Reagan
</pre>
<br>
<br>
Peter Doherty wrote:
<blockquote
 cite="mid:8E2DA0A7-BC9E-40FF-8F7A-B38F0458CCD8@crystal.harvard.edu"
 type="cite">
  <pre wrap="">On Mar 13, 2009, at 5:25 PM, Keith Erekson wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">I found this in my mailing list archives, while looking for  
information about check_ntp_peer. As far as I can tell, nobody ever  
answered you...

I was just looking into this exact problem. If you check the verbose  
output, you will probably see something like this:

0 candiate peers available
warning: no synchronization source found
warning: LI_ALARM bit is set

I do get valid output from "ntpq -p hostname", however.

Apparently, the problems with OS X's NTP are well-known and  
documented. For example,

<a class="moz-txt-link-freetext" href="http://knol.google.com/k/dirk-h-schulz/time-synchronization-ntp-on-mac-os-x/2bcee0ik2900p/18#">http://knol.google.com/k/dirk-h-schulz/time-synchronization-ntp-on-mac-os-x/2bcee0ik2900p/18#</a>
<a class="moz-txt-link-freetext" href="http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.5">http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.5</a>

As a way around this, I thought I would just use check_ntp_time, to  
compare the xserve's clock against that of the nagios box. However,  
no luck there either:

sending request to peer 0
response from peer 0: offset -0.9300264975
sending request to peer 0
response from peer 0: offset -0.9299369976
sending request to peer 0
response from peer 0: offset -0.9299154976
sending request to peer 0
response from peer 0: offset -0.9298709977
discarding peer 0: stratum=0
overall average offset: 0
NTP CRITICAL: Offset unknown|


It seems that OS X is responding as a stratum 0 server, which is a  
no-no.

Also, while fiddling with check_ntp_peer, I noticed that it doesn't  
seem to accept a port (-p or --port), as the help output suggests it  
should be able to. Am I crazy?

-Keith
    </pre>
  </blockquote>
  <pre wrap=""><!---->

Yeah, after a little more diagnostic work I eventually concluded that  
it was just OS X's implementation of NTP that is just broke.  It seems  
to be in sync for a while, then it just forgets it for a while, and  
eventually, maybe it'll sync up again.

Maybe they'll fix that for 10.6 this year.

--Peter


------------------------------------------------------------------------------
_______________________________________________
Nagios-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nagios-users@lists.sourceforge.net">Nagios-users@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/nagios-users">https://lists.sourceforge.net/lists/listinfo/nagios-users</a>
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null
  </pre>
</blockquote>
</body>
</html>