Compare NTPD and ntpdate

What are the pros and cons between these two ways to synchronize your server?

It seems to me that your server would probably not drift more than 1 second every day, so ntpdate on a crontab would be ok. But I heard you could use redundant NTP servers here

http://www.pool.ntp.org/en/use.html

in order to maintain synchronized time in case of failure.

Do you have any suggestions?

Solution 1:

The NTP algorithm includes information to allow you to calculate and fix the drift in your server's clock. NTPD includes the ability to use this to keep your clock in sync and will run more accurately than a clock on a computer not running NTPD. NTPD will also use several servers to improve accuracy.

ntpdate does not keep any state to perform this service for you so will not provide the same kind of accuracy. It will allow you to provide it with a list of servers which it will use to attempt to provide you with a better result but this is no substitute for the sophisticated algorithms provided in NTPD that track your drift from each of the servers over time.

NTPDATE corrects the system time instantaneously, which can cause problems with some software (e.g. destroying a session which now appears old). NTPD intentionally corrects the system time slowly, avoiding that problem. You can add the -g switch when starting NTPD to allow NTPD to make the first time update a big one which is more or less equivalent to running ntpdate once before starting NTPD, which at one time was recommended practice.

As for security concerns, ntp servers do not connect back on uninitiated connections, which means your firewall should be able to tell that you initiated the ntp request and allow return traffic. There should be no need to leave ports open for arbitrary connections in order to get NTPD to work.

From the ntpdate(8) man page:

ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time. This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.

Solution 2:

ntpd is preferred over ntpdate because you get smooth time correction rather than jumps in your clock. What sense do you make of your logs when there's a backwards time jump in them? ntpdate will also transparently switch between servers as needed.

As for requiring open ports (as mentioned by Kyle), newer versions of ntpd (e.g. 4.2.4 on my Debian server) can be configured to broadcast/multicast to the LAN, with cryptographic authentication.

Edit: see also this question.

Solution 3:

I generally recommend that you run NTPD, and sync your servers with a designated time server within your organization. That internal server will typically be syncing with one of the public NTP servers (as you linked to).

I have used the ntpdate method without any problem, but it just seems more hackish than running a true ntpd daemon.

Solution 4:

I have heard of issues with clock skew on virtual machines running ntpd. I have also heard of people correcting this issue by running regular cron jobs that call ntpdate against several of the pool servers. I've not had these problems, but I've heard of them several times.