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.
ntpdate and ntpd were historically the standard for syncing clocks on GNU/Linux machines. ntpd can still be used but there are several other modern alternatives one may want to consider.
Client / Desktop Configuration
There are several alternatives you can use to synchronize your click with NTP. You should make sure you are only using one. The most popular alternatives are:
- chronyd - Default on Fedora
- ntpd - The most widely used network time servers. Primarily for servers, can also be used on desktops
- rdate - small, light, does not run as a daemon. Can be used as a startup-job or cron job
- systemd-timesyncd - Comes with systemd, most distributions have it installed (but not activated by default)
Howto Sync Your Clock With The Chrony Daemon
chronyd is a fully featured time synchronization daemon which is similar to ntpd. It is a good choice for network time synchronization and it is the default network time client on Fedora. It is configured by the configuration file /etc/chrony.conf which does not need to contain much. If can look like this:
pool 0.pool.ntp.org iburst pool 1.pool.ntp.org iburst minsources 1 driftfile /var/lib/chrony/drift makestep 5.0 3 rtcsync keyfile /etc/chrony.keys leapsectz right/UTC logdir /var/log/chrony
The pool directives are the most important parts of a chronyd configuration file. The makestep directive is also worth noticing. The chrony.conf manual[1] explains its arguments as makestep threshold limit. It makes chrony adjust the system clock to real time if the clock is more than threshold out of sync - but only if chrony has done less than threshold adjustments. makestep 5.0 3 makes chrony harshly adjust the clock if it is more than five seconds out of sync upon boot. chrony will normally gradually smoothly adjust the clock. That is ideal but not if the clock is wildly out of sync.
minsources 1 makes chronyd adjust the clock even if there is just one clock source available. You may want to use minsources 5 if you configure a lot of pools and do not want any adjustments to take place unless there are five clock sources available.
rtcsync makes chronyd adjust the system clock.
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:
[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 RootDistanceMaxSec, PollIntervalMinSec and PollIntervalMaxSec in this example are the defaults[2]. The important values to change are NTP and FallbackNTP.
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
- See also: systemd-timesyncd
Howto Sync Your Clock With rdate
rdate is a a light-weight client/desktop alternative for synchronizing your clock. It does have some limitations. Most importantly, it adjusts the clock and walks away, it does not run as a daemon or care what time the system thinks it is after adjusting the clock once when it is executed.
chronyd, systemd-timesync and or ntpd will smoothly and gradually adjust the clock. This is good because some software will become very confused if the clock suddenly and unexpectedly jumps 30 minutes back or forth. rdate will simply set the clock to whatever time it is, if the system clock is two hours off and rdate runs then the clock is adjusted by two hours.
rdate does have one advantage: it is very small and light-weight. The original rdate binary is just 3kb and the more common openrdate is about 30kb. Both are used the same way: rdate -p timeserver[3] 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.
Howto Sync 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.
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
then
systemctl enable ntpd systemctl start ntpd
Once ntpd is running you can use ntpstat to verify that it is synchronizing.
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[4].
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.
Network Time Protocol 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.
There are two good choices:
- chronyd, which is fully featured and modern, and
- ntpd, which is a old and very well tested time server.
Configuring A ntpd Time Server
Here's a nice "standard" configuration file for a ntpd 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-
Testing your NTP configuration
ntpq, the NTP query program, can give you all sorts of interesting information about your timeserver. Running
ntpq -pn
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
Another example:
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 83.251.208.60 .PPS0. 1 u 15 64 1 20.583 -3.385 0.000 91.209.0.19 194.58.204.148 2 u 14 64 1 10.177 -0.697 0.000 83.168.200.198 194.58.202.20 2 u 14 64 1 5.476 -1.751 0.000 91.216.111.52 244.77.152.229 2 u 12 64 1 6.159 -1.148 0.000 193.228.143.13 194.58.202.148 2 u 13 64 1 12.826 2.533 0.000 91.209.0.20 232.6.188.111 2 u 10 64 1 8.490 -1.354 0.000 217.75.106.216 194.58.202.20 2 u 9 64 1 5.962 -1.163 0.000 83.168.200.199 194.58.202.20 2 u 10 64 1 6.219 -1.340 0.000
ntpq manpage[5] story is:
-n
|
Output all host addresses in dotted-quad numeric format rather than converting to the canonical host names. |
-p
|
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
Running 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.
Configuring A Chrony Time Server
A chronyd time server meant to serve a LAN is configured mostly the same way a chronyd client meant to serve the box it is running on is. A server configuration can look like this:
pool 0.pool.ntp.org iburst pool 1.pool.ntp.org iburst pool 2.pool.ntp.org iburst pool 3.pool.ntp.org iburst driftfile /var/lib/chrony/drift makestep 5.0 3 rtcsync allow 192.168.0/24 local stratum 10 keyfile /etc/chrony.keys leapsectz right/UTC logdir /var/log/chrony
The above configuraiton file is mostly the same as you would use to syncronize time on a single computer with two exceptions worth paying attention to:
allow 192.168.0/24 local stratum 10
The allow directive opens the door for other computers on the network. It should have a subnet and a prefix as an argument.
local stratum 10 tells the NTP clients on the network that the NTP server is not using a primary clock source. You could use 3 too. Servers with a real clock source (GPS, etc) are stratum 1, servers connecting directly to a server with a real clock source are stratum 2. What higher number you use beyond that is kind of irrelevant, just be aware that you should not use 1 or 2 since your networks time server isn't a going to be a primary or secondary clock source.
You will have to make sure clients who are going to use the network time server have access to UDP port 123. chronyd does not listen to any TCP ports.
Picking Network Time Servers
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[6] will work just fine anywhere:
pool 0.pool.ntp.org pool 1.pool.ntp.org pool 2.pool.ntp.org
There are local regional ntp pools for most parts of the world. This ensures that the ntp servers are relativily close. As an 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:
| Asia | asia.pool.ntp.org |
| Europe | europe.pool.ntp.org |
| North America | north-america.pool.ntp.org |
| Oceania | oceania.pool.ntp.org |
| South America | south-america.pool.ntp.org |
There's also local country pools such as dk.pool.ntp.org (Denmark), fr.pool.ntp.org (France), etc. They are typically available as digit.countrycode.pool.ntp.org like:
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 then you could use those and use servers instead of a pool. Specify them by DNS/name if you go that route. Example:
server ntp.uio.no server gbg1.ntp.se server gbg2.ntp.se server sth1.ntp.se server sth2.ntp.se
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". |
The program 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 option. -q means "Query only - don't set the clock"[7]. 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.
Some examples:
$ ntpdate -q ntp.time.nl server 2a00:d78:0:712:94:198:159:10, stratum 1, offset 0.005731, delay 0.06699 server 94.198.159.10, stratum 1, offset 0.004027, delay 0.06264 4 Dec 21:38:28 ntpdate[1745229]: adjust time server 94.198.159.10 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.
Another example:
$ ntpdate -q ntp.uio.no server 2001:700:100:2::6, stratum 2, offset 0.003351, delay 0.04016 server 129.240.2.6, stratum 2, offset 0.001663, delay 0.03783 4 Dec 21:38:04 ntpdate[1725109]: adjust time server 129.240.2.6 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 143.107.229.211, stratum 1, offset -0.002947, delay 0.27168
4 Dec 21:48:10 ntpdate[2257544]: adjust time server 143.107.229.211 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.
References
- ↑ chrony.conf manual
- ↑ timesyncd manual page
- ↑ RDATE manual page
- ↑ Novell: It's Fudge Time
- ↑ man.linuxreviews.org: ntpq.8 manual
- ↑ pool.ntp.org
- ↑ ntpdate manual
Enable comment auto-refresher