How to keep your Linux system clock accurate

That wraps up the three blocks of time in our diagram: hardware, managing and sources. Let's circle back around for a sequel to managing time by opening a terminal for some more management.

First check to see if a time keeper program is installed and running. There are a number of possible ways to accomplish this task. Here are some suggestions...

Linux system time

The -n switch enables a DNS lookup of 0.pool.ntp.org. The URL used in our example is a front for a pool of servers. Don't expect to get the same IP shown in our output as it will vary.

Just after start it will look like this:

[root@fedora19]# ntpq -n -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
142.137.247.109 209.51.161.238 2 u 2 64 1 43.446 3.550 0.000

[root@fedora19]# ntpq -c assoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 58621 9024 yes yes none reject reachable 2

After 4 minutes, it will look like this:

[root@fedora19]# ntpq -n -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*142.137.247.109 209.51.161.238 2 u 4 64 17 43.300 4.534 0.838

[root@fedora19]# ntpq -c assoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 58621 963a yes yes none sys.peer sys_peer 3

The commands were issued once when the daemon was started and again four minutes later. The line around the condition field indicates that the source is being used as a peer.

The line around the remote field is to draw attention to the asterisk. This indicates that the daemon has successfully peered with the source for time input.

For more information on the ntpq tool, the de facto resource for all documentation is on the University of Delaware website.

What do you do if the daemon is not peering with a source? This is a good time to break out the packet sniffer to see if our daemon is functioning.

This will enable us to check if the daemon is sending out a time request and receiving a reply. You can confirm the port number used by ntp or other services by examining the /etc/services file – see the red No.1 in the screenshot for the output of this command:

sudo tcpdump -i port 123

The output of tcpdump displays the daemon's call to the external time source every minute. There don't appear to be any replies being received. A quick check of the local firewall reveals a closed port 123 on the firewall. Look at the same tcpdump output: a reply was received once the port was opened.

If you don't see requests being sent then the issue rests with the daemon; it may not have started. Check your install and configuration file.

Securing ntpd

The ntp daemon by default is open and very chatty when queried (see the green No.2 in screenshot for the output). This information enables other computers to get the status and more details. Reading the output is a simple way to tell what kernel a system is running.

The security conscious may want to curtail the daemon's propensity to speak out. Edit the /etc/ntp.conf configuration file by removing the # and Line 1-4 text. You should now have a total of five lines. Don't forget to save the file after making the changes. Restart the daemon to read the configuration changes using

sudo systemctl restart ntpd

or

sudo service ntp restart

Lines 1-2 (counting the very first line as Line 0, of course – we're computer geeks!) allow time synchronisation with another source but don't allow the source to interrogate or make changes to the daemon. Lines 3-4 enable loopback access and disable others. The reason for two config lines is to cover off configuration for IPv4 and IPv6 protocols.

Running the same query commands as before, we find that the daemon isn't responding to requests. Edit the /etc/ntp.conf configuration file by removing the # and Line 5-7 text, and restart the daemon to read the configuration changes.

Lines 5-6 enable the daemon to use the hardware clock as a time source, if external sources aren't available. Line 7 enables the daemon to record the hardware clock's drift from system clock in a file. This information assists the daemon on power-down restarts. A simple ntp print query displays the local time source in the output – see the blue No. 3 in the screenshot for the output:

mv /etc/ntp.conf.org /etc/ntp.conf

Using a text editor, examine /etc/ntp.conf for commented entries. If you plan to use this config file for your installation, you'll need to add your server selections and/or remove the default entries.

Let's finish off back at the hardware clock. The hardware clock values are read with

hwclock -r

and written from the system clock to the hardware clock with:

hwclock -w

The man pages suggest running the write command periodically to compensate for the hardware clock drift.

There you have it, taking care of business and working over time – an examination of Father Time provided by the ntp daemon. The ntp program follows the client-server model and can be used to set time or even to distribute time as a broadcast. Those titbits of time distribution configuration you can discover in the original configuration file.

TOPICS