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:

  1. Correct for time at boot-up quickly where the clock has a large skew.

  2. Provide a configuration that guards and/or corrects for situations where the clock can sometimes develop a large skew over time.

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


Many of the pieces that will provide the "ultimate" solution are spread across the U&L site in questions such as these:

There are bound to be others but these are the ones that I've seen that come to mind as being relevant.

  • 1
  • 1
    FYI: Planning on working on a comprehensive answer to this. See the chat log starting at chat.stackexchange.com/transcript/message/11350138#11350138
    – derobert
    Sep 23, 2013 at 16:32
  • #2 should not happen if ntpd is running
    – dfc
    Sep 28, 2013 at 0:48
  • @dfc - this can happen when a VM is paused and then later resumed, there are other situations where it can happen too.
    – slm
    Sep 28, 2013 at 0:51
  • @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?
    – dfc
    Sep 28, 2013 at 1:02

3 Answers 3


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.

  • If ntpd is running successfully why do you need to stop and start it? This seems like a terrible idea.
    – dfc
    Oct 5, 2013 at 3:29
  • 4
    ntpdate won't work if ntpd is running.
    – Grizly
    Oct 10, 2013 at 4:29
  • I think the question was not "Why restart ntpd?", but "Why use ntpdate after ntpd had sync'ed the time?"
    – U. Windl
    Nov 2, 2020 at 9:25

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.

  • typing ntpd --panicgate and then date does absolutely nothing
    – AlxVallejo
    Apr 27, 2016 at 16:46
  • Do you modify init files to pass -g or is there an equivalent option to set in ntp.conf?
    – Jérôme
    Oct 10, 2018 at 9:20
  • I 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.
    – Jérôme
    Oct 10, 2018 at 9:35

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/

  • 1
    This answer definitely lacks reasoning: Why? What are the benefits?
    – U. Windl
    Nov 2, 2020 at 9:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .