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
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
