On Jun 4, 2012, at 2:42 PM, John R Pierce wrote: > On 06/04/12 1:27 PM, Nate Duehr wrote: >> Additionally, ntp will refuse to sync if it's too far out. Use ntpdate [server IP] to force the issue first. If the machines have a bad CMOS battery and won't keep time, ntpdate package can be configured to force time sync (which is a bad hack) at boot-time. > > the standard EL5 /etc/rc.d/init.d/ntpd script does this automatically, > unless its been disabled via /etc/sysconfig/ntpd Interesting. I hadn't looked at the scripts in a while. The reason no one ever did it "in the old days" was for fear of an NTP server going out of whack. ntpdate should be used sparingly and with knowledge that one is doing it... automating it is usually a bad idea. (Especially by default.) As I said in the original reply, it's a nasty hack. IMHO, ntpdate package install should be just to get the tool installed, no automation. If it's installing automated setting by default, that's not right. One should have to turn ON automated ntpdate at startup/shutdown after understanding the risk. >> After getting the clock in sync, "hwclock --systohc" to push it into the CMOS clock. > > setting SYNC_HWCLOCK=yes in said above config file will do this, too. Was just giving him the way to do it in real-time. The config file only does it at startup/shutdown, last I looked. Haven't looked recently. Sounds like there's been some goofy decisions made somewhere along the line for ntp and ntpdate... an NTP server can be compromised and date/time changed across an envrionment (or more likely, it can have some type of failure itself...) and the old tenets of ntp were there for a reason... 1. ntp doesn't sync if it's too far out of whack... 2. ntpdate should be operated by hand... not automated... Oh well. Those unwilling to learn from past mistakes are doomed to repeat them, right? (GRIN!) Nate