HOWTO ensure your clock is accurate and showing the correct time using the Network Time Protocol
The Network Time Protocol (NTP) has been the standard for accurate clocks on devices connected to the Internet for a very long time. Here's how you can set it up on your Linux system to ensure your clock is accurate.
Traditionally ntpdate and ntpd was the standard for syncing clocks on GNU/Linux machines. Today systemd's timesyncd is the common way of doing it.
- 1 Howto Sync Your Clock With systemd-timesyncd
- 2 rdate - A Light-Weight client/desktop Alternative for Syncing Your Clock
- 3 Syncing Your Clock With ntpd
- 4 Picking Your Timeservers
- 5 Testing your NTP configuration
- 6 References
Howto Sync Your Clock With systemd-timesyncd
First, change the configuration file
/etc/systemd/timesyncd.conf to your preferences. Here's a globally usable example you can cut and paste:
The values for
PollIntervalMaxSec in this example are the defaults. The important values to change are
The example above will actively use two of the global NTP pools and fallback to two others if those fail. This, of course, means that you would be screwed if ntp.org were to fail. See Picking timeservers to choose better ones for your location.
Once you're happy with your systemd-timesyncd configuration you should start it and enable it:
systemctl start systemd-timesyncd systemctl enable systemd-timesyncd
rdate - A Light-Weight client/desktop Alternative for Syncing Your Clock
Using ntpd to sync your clock is good because it kind of smooths things over and gradually adjusts the system clock. This is good because some software will become very confused if the clock suddenly and unexpectedly jumps 30 minutes back or forth. systemd-timesync tries to do the same kind of smooth adjustment.
If you do not like those two options then there's a third alternative: rdate. Good old rdate. The original rdate binary is just 3kb and the more common openrdate is about 30kb. Both are used the same way:
rdate -p timeserver as in
rdate -p 0.pool.ntp.org
rdate is something you could run once upon boot or put on a hourly or daily cron schedule if you want a bare minimum of services running in the background. Do note that adjusting the clock daily with a rdate cron job may cause problems if your system clock is wildly inaccurate; rdate will set the clock to the time the ntp server it contacts reports - it will NOT do gradual smooth adjustments.
Syncing Your Clock With ntpd
ntpd is a full-fledged time-server. You can use it to sync the clock on your own computer or run a timeserver service on your local network which can be used by other machines and devices.
The ntpd package is simply called ntpd on most distributions and it is installed in the usual manner (
dnf -y install ntp /
yum install ntp /
apt-get install ntp /
emerge ntp depending on distribution).
You need version ntp-4.2.5p16 or later to listen on IPv6 addresses.
Client (Desktop) NTPD Configuration
Most people just need a nice client setup which asks timeserver(s) what time it is and adjusts the local clock accordingly. The default /etc/ntp.conf configuration file is actually quite cool out-of-the-box most distributions but you may want to change it anyway. Here's an example of a simple client setup:
Take note of the use of pool in the above example. You can also use server if you are specifying that you want to use one single all-alone timeserver and not a pool.
If you are going to use ntp on modern distributions you will want to mask systemd-timesync and enable ntpd:
systemctl stop systemd-timesyncd systemctl disable systemd-timesyncd systemctl mask systemd-timesyncd
systemctl enable ntpd systemctl start ntpd
Once ntpd is running you can use
ntpstat to verify that it is synchronizing.
What the fudge?
There are two lines in the above example which require some explanation:
server says that the local system clock is a timeserver. fudge says that this server is stratum 10. If you are connected to the Internet then you are likely using timeservers who are more l33t than stratum 10 what time it is, and these servers are used because they have lower stratum and thus; higher priority.
However, if you are disconnected from the Internet then they are unavailable and you're left with the local clock. Using fudge to say that the local clock is stratum 10 makes ntp use the local clock when no timeservers are available. This is good because it makes sure you can disconnect your box from the Internet without getting your clock screwed.
NTP Time Server configuration
You much likely want to run your own NTP server if you are a huge and profitable corporation, intelligence service or just a private citizen who happen to control a really large network.
The reason is this: Only one box really needs to get the correct time from the outside. This box can act as a timeserver and tell the rest of the boxes on your network what time it is.
Here's a nice "standard" configuration file for a timeserver:
Notice that this is basically the same configuration as the client example except that in the client example the very important restrict lines are
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery
while on a server the restrictions are just
restrict default kod nomodify notrap restrict -6 default kod nomodify notrap
A notice on Firewall setup: It must be possible to connect to port 123, both UDP and TCP, from the outside / all boxes who will be (ab)using your timeserver.
A notice on restrictions: restrict is probably the least understood part of ntpd configuration. In the above example
- kod makes ntpd send a "kiss-o'-death (KoD) packet" when something violates it
- nomodify makes run-time state and configuration modification impossible. Perhaps you'd like to setup keys and use ntpq and ntpdc to do this but you likely don't.
- noquery will deny queries from ntpq and ntpdc and does not deny time service queries-
Picking Your Timeservers
There are two things to consider when picking timeservers: Distance (d), and stratum. stratum really means "How l33t is this sever?". Servers who are able to figure out what time it is all on their own using an external source - not the Internet - are very l33t and thus; Stratum 1. Servers using an atomic clock or satellite systems like GLONASS and GPS are considered to be Stratum 1.
The Simple And Lazy Way To Pick Timeservers
Laziest Way To Pick Timeservers is to use a global or regional pool,
The global ntp poool pool.ntp.org will work just fine anywhere:
There are local regional ntp pools for most parts of the world. This ensures that the ntp servers are relativily close. As an example:
Other continents where you have [0-3].continent.pool.ntp.org are:
There's also local country pools such as dk.pool.ntp.org (Denmark), fr.pool.ntp.org (France), etc. They are typically available as
If you know there are good local timeservers in your area and you know their names then you could use those and use servers instead of a pool. Specify them by DNS/name if you go that route. Example:
The Cumbersome Way Of Picking NTP servers
|TIP: Going with your countries NTP pool is simpler and quicker than manually querying a lot of time servers in order to fine one you "like".|
ntpdate, which is NOT part of the regular
ntp package - you will have to install
ntpdate separately - can be used to check time-servers with it's
-q means "Query only - don't set the clock". Querying a working ntp time server with
ntpdate -q hostname will print out some details about the time server. Querying a host which is not running a working time-server will output
no server suitable for synchronization found.
$ ntpdate -q ntp.time.nl server 2a00:d78:0:712:94:198:159:10, stratum 1, offset 0.005731, delay 0.06699 server 126.96.36.199, stratum 1, offset 0.004027, delay 0.06264 4 Dec 21:38:28 ntpdate: adjust time server 188.8.131.52 offset 0.004027 sec
The above indicates that
ntp.time.nl is a working ntp time server with both IPv4 and IPv6 connectivity. It is a
stratum 1 which means that it has it's own clock-source.
$ ntpdate -q ntp.uio.no server 2001:700:100:2::6, stratum 2, offset 0.003351, delay 0.04016 server 184.108.40.206, stratum 2, offset 0.001663, delay 0.03783 4 Dec 21:38:04 ntpdate: adjust time server 220.127.116.11 offset 0.001663 sec </code> The above shows that <code>ntp.uio.no</code> is also a working ntp time server with both IPv4 and IPv6 connectivity. This server is a <code>stratum 2</code> server which means that it has no way of keeping track of time on it's own. It can only ask <code>stratum 1</code> servers who do have GPS or an atomic clock or something else to rely on. '''The <code>delay</code> part of <code>ntpdate -q</code> is worth a close-up inspection if you do decide to manually pick and choose the time-servers you use.''' <code>lrte.ntp.ifsc.usp.br</code> is a working NTP server which is part of the <code>south-america.pool.ntp.org</code> NTP pool. Consider this response when querying <code>ntpdate -q lrte.ntp.ifsc.usp.br</code> from Europe:
server 18.104.22.168, stratum 1, offset -0.002947, delay 0.27168
4 Dec 21:48:10 ntpdate: adjust time server 22.214.171.124 offset -0.002947 sec
The delay of 0.27168 may not appear to be huge but it is compared to the in-comparison small 0.04016 delay to local NTP servers.
The page IPv6-listening NTP servers has a list of NTP servers with IPv6 connectivity. It is less relevant than it was when it was first created in 2008 since most NTP servers supports IPv6 these days.
Testing your NTP configuration
ntpq, the NTP query program, can give you all sorts of interesting information about your timeserver. Running
will print out all kind of incriminating evidence about your time-server such as:
remote refid st t when poll reach delay offset jitter 127.127.1.0 .LOCL. 10 l 52 64 1 0.000 0.000 0.000 2001:610:508:11 .GPS. 1 u 51 64 1 45.997 5.521 0.000
remote refid st t when poll reach delay offset jitter 0.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.000 1.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.000 2.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.000 127.127.1.0 .LOCL. 10 l 15 64 1 0.000 0.000 0.000 126.96.36.199 .PPS0. 1 u 15 64 1 20.583 -3.385 0.000 188.8.131.52 184.108.40.206 2 u 14 64 1 10.177 -0.697 0.000 220.127.116.11 18.104.22.168 2 u 14 64 1 5.476 -1.751 0.000 22.214.171.124 244.77.152.229 2 u 12 64 1 6.159 -1.148 0.000 126.96.36.199 188.8.131.52 2 u 13 64 1 12.826 2.533 0.000 184.108.40.206 220.127.116.11 2 u 10 64 1 8.490 -1.354 0.000 18.104.22.168 22.214.171.124 2 u 9 64 1 5.962 -1.163 0.000 126.96.36.199 188.8.131.52 2 u 10 64 1 6.219 -1.340 0.000
ntpq manpage story is:
|Output all host addresses in dotted-quad numeric format rather than converting to the canonical host names.|
|Print a list of the peers known to the server as well as a summary of their state. This is equivalent to the peers interactive command.|
There is a perl script called ntptrace available on older systems which can be used as a command-line front-end for ntpq. It has not been updated in decades and does not appear to be available on modern systems.
Most distributions have a package called
ntpstat which can show some basic information about a NTP server available. It will show less useful information like:
synchronised to NTP server (2a01:3f7:4:1::1) at stratum 2 time correct to within 16 ms polling server every 64 s
ntpq -pn will give you a lot more detailed information;
ntpstat is not useful for more than verifying that a ntp server is working.
If most of your servers are showing a very high delay then it's worth considering using another server and/or pool.