Do "service ntpd restart" and "ntpdate <ntp-server-ip>" do the same work?

Question

I often get large offsets when checking ntpd using 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.

Answer 1

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

Answer 2

No. Citing man ntpdate:

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.

Answer 3

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:

1. Not including enough peers - you should have at least 4. Read through the whole BCP draft if you have the time.
2. Using the server with the public NTP pool instead of the newer pool directive - you should use the latter if your ntpd supports it.
3. 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.)
4. There might be other reasons why your server is struggling to keep good time, such as a kernel bug or poor hardware clock. Enabling loopstats, peerstats, and sysstats in your ntp.conf should 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.