[CentOS] system date using ntp client is drifting

Les Mikesell

lesmikesell at gmail.com
Mon Jun 4 23:21:07 UTC 2012


On Mon, Jun 4, 2012 at 5:51 PM, Nate Duehr <denverpilot at me.com> wrote:
>
>
> 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.

Historically, hardware clocks that are way off at power up have been
very common.  It might better on current devices.

> 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.

There's not too much risk from a big time jump at startup before most
of your applications are doing anything.  That seems much safer than
waiting with a time difference that ntp itself won't fix and would
take forever with it's fractional-second jumps if it tried.

> 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...
>

Well, yes, but the cheap clocks and batteries in PCs are there for a
reason too (not necessarily a good reason...) and that's what we've
had to live with.   I do usually run ntp on routers and sync from the
ones nearby.   Ciscos at least won't act as servers unless they are
fairly confident about their own sources so there's not much chance of
picking up a bad starting time.   And you need to specify multiple
servers to cover failures.

-- 
   Les Mikesell
      lesmikesell at gmail.com



More information about the CentOS mailing list