What is the recommended way to synchronize time using NTP?
Solution 1
Since you cannot correct large deviations in time using ntp (unless you have a few hours for the clock to catch up or slow down) I do this:
service ntpd stop ntpdate us.pool.ntp.org service ntpd start
I cron it for once a day, everyday. I also put ntpdate in an init script to run before ntp starts after bootup, since reboots and power cycles are the most likely/frequent events that mess with the system time.
Solution 2
What you're looking for is ntpd
with the --panicgate
option.
The panicgate option allows the first adjustment after ntpd
starts to be any size. This is exactly for the use case you described where a machine comes up and it's clock is wildly inaccurate. When ntpd starts with this option enabled, it can take a moment for it find a server and establish synchronization with it.
That option in itself solves your item #1.
#2 is vanilla ntpd. Ntpd keeps a drift file which is the rate your system's clock skews.
#3 is also the same as #1. The --panicgate
option isn't limited to immediately when ntpd starts, it is limited to "the first adjustment", whenever that adjustment is.
Solution 3
Use chronyd/chronyc instead of ntp/ntpdate. It's already default method in fedora and, I suppose, will be in RHEL 7.0 as soon as it ready.
Documentation can be found at http://chrony.tuxfamily.org/
Related videos on Youtube
slm
Worked in the tech field for over 20+ years. Started out learning basic on an Apple IIe then on a TRS-80. Been interested in computer hardware and software my entire life. Consider myself lucky that my hobby as a kid/adult is what I get to do everyday earning a living. You can learn more about me here. ============================================================ Stolen from @Mokubai: First, please put down the chocolate-covered banana and step away from the European currency systems. You may consider how to ask a question.
Updated on September 18, 2022Comments
-
slm over 1 year
This question has come up a number of times in a localized way, this question is meant to provide the preferred/best method for synchronizing a system's clock using NTP.
The solution should handle multiple issues correctly, such as:
Correct for time at boot-up quickly where the clock has a large skew.
Provide a configuration that guards and/or corrects for situations where the clock can sometimes develop a large skew over time.
A robust solution that can handle and sync the time quickly when certain problems arise such as: "the time server wasn't accessible during boot" or "the internet is inaccessible during boot".
The ideal solution would be a single NTP configuration file that is able to handle all this.
References
Many of the pieces that will provide the "ultimate" solution are spread across the U&L site in questions such as these:
- How to force the time and date settings to refresh from the internet?
- Time synchronization of machines on LAN to GPS NTP server on the LAN
- How can I make a Puppet module that fixes time?
- NTP not syncing in a VM
There are bound to be others but these are the ones that I've seen that come to mind as being relevant.
-
Admin over 10 years
-
Admin over 10 years#2 should not happen if ntpd is running
-
Admin over 10 years@slm "develops" means aone time jump in the skew after VM restart? It seems that within a couple of hours after restart ntpd should get the skew under control. Definitely not make it worse. What are the other situations?
-
Admin over 10 yearsFor more information on #3 take a look at bugs.debian.org/cgi-bin/bugreport.cgi?bug=683061 Id love to have a better solution than a cron script that periodically populates /etc/hosts with the information for my preferred tie servers.
-
Admin over 10 years@dfc - as would I. That's the rational behind this Q. We're attempting to get a conclusive answer and not a hacked together solution.
-
Admin over 10 yearsI added some comments to the outline. for some reason my comments are showing up as anonymous.
-
Admin over 10 yearsI'm inclined to think that the answer lies somewhere between "iburst" and "ntpdate <server>" before launching ntpd, thats how most distributions do it... iburst may well handle lacking internet at boot too as it stabalises quicker. I think you can set the max correction "fix-rate vs set clock" values too. Obviously if your clock is skewing over time and NTP isn't compensating for it (case 2), you broke NTP, because thats exactly what NTP was designed to get around, an unreliable drifting local clock. The case of VM suspends, well what do you expect-compensate for a clock that misses hours?
-
Admin over 10 years@iain iburst will not handle no internet at boot. iburst does not create an internet connection. iburst will set a clock quicker when there is a net connection but it does not magically create a network connection
-
Admin over 10 years@dfc - obviously no internet = no clock sync. iburst will send a burst when the server DOES become reachable, promoting the speed of the synchronisation overall. No-one's asking or answering "how do you sync with NTP when you have no external references ever" surely?
-
dfc over 10 yearsIf ntpd is running successfully why do you need to stop and start it? This seems like a terrible idea.
-
Grizly over 10 yearsntpdate won't work if ntpd is running.
-
AlxVallejo about 8 yearstyping ntpd --panicgate and then date does absolutely nothing
-
Jérôme over 5 yearsDo you modify init files to pass
-g
or is there an equivalent option to set inntp.conf
? -
Jérôme over 5 yearsI just realized
-g
is used already by default in my Debian install, but I don't know in which init/config file this is done. -
U. Windl over 3 yearsI think the question was not "Why restart ntpd?", but "Why use ntpdate after ntpd had sync'ed the time?"
-
U. Windl over 3 yearsThis answer definitely lacks reasoning: Why? What are the benefits?