[BBLISA] ntp question

[Sean Lutner]

On Mar 17, 2009, at 5:22 PM, Dave Pascoe wrote:

> This is a decent way to deal with it.
>
> You can also use check_ntpd in Nagios and restart ntpd as needed on
> hosts that appear to become unsynchronized.  The penalty for a false
> positive is small.
>
> Also, ntpdate should really be run right before starting ntpd.   
> ntpdate
> sets clocks that have become far off due to hardware clocks skew and
> then ntpd keeps everything in fine sync.

This is what the the /etc/ntp/step-tickers (on a redhat variant linux  
system anyway) is for. It's a list of systems to initially sync your  
clock against using ntpdate. If it's not configured in your  
environment, I highly recommend looking into it.

>
> I have also found ntpd stability highly variable on VMs.  Just running
> ntpdate there via cron seems like the path of least resistance.  On  
> some
> VM environments the host system already keeps the VMs in sync (it runs
> ntpd and auto-syncs the VM clocks).

I've seen drift issues on VMs, but it's gotten better with some recent  
patches from VMware (in ESX 3.5 update2) as well as some custom kernel  
settings to use a different frequency for the "hardware" clock of the  
host system. We wound up setting the frequency to 60Hz iirc.


>
> -Dave
>
>
> Rudie, Tony wrote:
>> ntpd isn't perfect at dealing with VMs either.  My organization has a
>> cron job to monitor ntpd and make sure the time is still accurate,
>> and there's some sophisticated logic there to minimize false
>> positives, but it still throws a couple of valid alerts every week,
>> (always on VMs.  The job runs everywhere, but...) and restart ntpd.
>>
>>
>> Actually, it's not a cron job.  The monitoring system runs the
>> check-script, and throws the alert based on return code.
>>
>>
>> - Tony Rudié
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>