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 How to sync your clock with systemd-timesyncd
- 2 Syncing your clock with ntpd
- 3 Picking your timeservers
- 4 rdate - The almost forgotten light-weight client/desktop alternatives to using ntpd
- 5 Testing your NTP configuration
- 6 References
How to 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:
[Time] NTP=0.pool.ntp.org 1.pool.ntp.org FallbackNTP=2.pool.ntp.org 3.pool.ntp.org RootDistanceMaxSec=5 PollIntervalMinSec=32 PollIntervalMaxSec=2048
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
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:
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 # Timeserver(s) to (ab)use pool 0.pool.ntp.org iburst pool 1.pool.ntp.org iburst pool 2.pool.ntp.org iburst pool 3.pool.ntp.org iburst pool 2.fedora.pool.ntp.org # not actually a server, it's your local clock server 127.127.1.0 fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift
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 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10
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:
restrict default kod nomodify notrap restrict -6 default kod nomodify notrap pool 0.pool.ntp.org pool 1.pool.ntp.org pool 2.pool.ntp.org server ntp6.remco.org prefer server chime3.ipv6.surfnet.nl server ntp1.ipv6.lrz-muenchen.de server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys /etc/ntp/keys
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.
Laziest Way To Pick Timeservers: Use pool.ntp.org. Their global pool:
pool 0.pool.ntp.org pool 1.pool.ntp.org pool 2.pool.ntp.org
There are local ntp pools for most parts of the world, for example:
pool 0.europe.pool.ntp.org pool 1.europe.pool.ntp.org pool 2.europe.pool.ntp.org pool 3.europe.pool.ntp.org
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.
pool 0.fr.pool.ntp.org pool 1.fr.pool.ntp.org pool 2.fr.pool.ntp.org pool 3.fr.pool.ntp.org
If you know there are good local timeservers in your area and you know their names you should use those and use server instead of pool to specify them. Example:
server ntp.uio.no server gbg1.ntp.se server gbg2.ntp.se server sth1.ntp.se server sth2.ntp.se
rdate - The almost forgotten light-weight client/desktop alternatives to using ntpd
Using ntpd is good because it kind of smooths things over and gradually adjusts the system clock. This is good because some software may become very confused if the clock suddenly and unexpectedly jumps 5 minutes back or forth. systemd-timesync tries to do the same.
If you do not like those two 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.
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 22.214.171.124 .PPS0. 1 u 15 64 1 20.583 -3.385 0.000 126.96.36.199 188.8.131.52 2 u 14 64 1 10.177 -0.697 0.000 184.108.40.206 220.127.116.11 2 u 14 64 1 5.476 -1.751 0.000 18.104.22.168 244.77.152.229 2 u 12 64 1 6.159 -1.148 0.000 22.214.171.124 126.96.36.199 2 u 13 64 1 12.826 2.533 0.000 188.8.131.52 184.108.40.206 2 u 10 64 1 8.490 -1.354 0.000 220.127.116.11 18.104.22.168 2 u 9 64 1 5.962 -1.163 0.000 22.214.171.124 126.96.36.199 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.
If most of your servers are showing a very high delay then it's worth considering using another server and/or pool.