Installing NTP-related packages

Kudu has been well-tested to work on machines whose clock is synchronized with ntpd, the NTP server from the ubiquitous NTP suite.

To install ntpd and other NTP-related utilities, use the command appropriate for your operating system:


OS	Command
Debian/Ubuntu	`sudo apt-get install ntp`
RHEL/CentOS	`sudo yum install ntp`

If ntpd is installed but not running, update it by running the ntpdate command and then restart it by using command appropriate for your operating system:


OS	Command
Debian/Ubuntu	`sudo service ntp restart`
RHEL/CentOS	`sudo service ntpd restart`

Make sure that the ntpdate is in the list of services running when the machine starts. The ntpdate command should be run first before starting ntpd to avoid long synchronization delay of the machine's local clock with the true time. The smaller the offset between local machine's clock and the true time, the faster the NTP server can synchronize the clock.

When talking about the 'synchronization' with true time using NTP, we are referring to:

The synchronization status of the NTP server which drives the local clock of the machine
The synchronization status of the local machine's clock itself as reported by the kernel's NTP discipline

The former can be retrieved using the ntpstat, ntpq, and ntpdc utilities (they are included in the ntp package). The latter can be retrieved using the ntptime utility (the ntptime utility is also a part of the ntp package). For more information, see the manual pages of the mentioned utilities and the following section:

Sometime it takes too long to synchronize the machine's local clock with the true time even if the ntpstat utility reports that the NTP daemon is synchronized with one of the reference NTP servers. This manifests as the following: the utilities which report on the synchronization status of the NTP daemon claim that all is well, but ntptime claims that the status of the local clock is unsynchronized and Kudu tablet servers and masters refuse to start, outputting an error like the one mentioned above. This situation often happens if the ntpd is run with the -x option. According to the manual page of ntpd, the -x flag configures the NTP server to only slew the clock. Without -x, the NTP server would do a step adjustment instead:

-x
Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and is stepped if the offset is above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually.

For more information on best practices and examples of practical resolution of various NTP synchronization issues, see clock-drift