I often get large offsets when checking
ntpq -p, I generally restart the ntp daemon and it fixes the issue. I wanted to know if i can try the
ntpdate <ntp-server-name> instead of restarting
ntpd. Since this is a production box wanted to be sure before implementing it.
ntpdate will decline to set the date if an NTP server daemon (e.g., ntpd) is running on the same host. When running ntpdate on a regular basis from cron as an alternative to running a daemon, doing so once every hour or two will result in precise enough timekeeping to avoid stepping the clock.
ntpd are different tools, but one of them helps another.
ntpdate is used to synchronize the system clock at once immediately. It takes time from a
ntpd server, which has synchronized status (stratum 1 - 4).
ntpd service sets system clock softly. It can spend several hours to eliminate the lag of system clock for several minutes. All this time it has synchronized status
stratum 16 - it means the system clock isn't synchronized. The service restart command
service ntpd restart is used only to apply changes in its configuration file.
ntpdate is usually used to synchronize the system clock of personal computer at startup.
ntpd service is usually used to synchronize the system clock of server all-time.
On various commonly-used Linux distributions (including CentOS, Debian, and Ubuntu),
ntpd is started with the
-g flag by default, which means it will perform a large clock step on the first adjustment if needed. So for the majority of cases,
ntpdate shouldn't be needed, and restarting
ntpd would be preferred.
But, as Sven commented, if
ntpd has been running for a while and you still end up with a large offset, then something's wrong with your NTP setup or your network (or both).
So rather than restarting
ntpd or running
ntpdate, try diagnosing why you end up in this situation in the first place.
Some common issues:
- Not including enough peers - you should have at least 4. Read through the whole BCP draft if you have the time.
- Using the
serverwith the public NTP pool instead of the newer
pooldirective - you should use the latter if your
- Using peers which are too far away or poorly connected - try to select close-by, reliable peers. Even better, augment your external peers with a local reference clock for your network. (A BeagleBone, Raspberry Pi, or LeoNTP with a GPS receiver might be a good choice, depending on your environment.)
- There might be other reasons why your server is struggling to keep good time, such as a kernel bug or poor hardware clock. Enabling
ntp.confshould help to track this down.
Post your configuration and the output from
ntpq -np and hopefully we should be able to help you work this out.