ITKarma picture

Most people keep track of time. We get up on time to complete our morning rituals and go to work, take a break for lunch, meet the project deadlines, celebrate birthdays and holidays, board a plane and so on.

Moreover: some of us are obsessed with time. My watch is powered by solar energy and receives the exact time from the National Institute of Standards and Technology ( NIST ) to Fort Collins, Colorado via the WWVB longwave radio station. Time signals are synchronized with the atomic clock, also located at Fort Collins. My Fitbit syncs with my phone, which syncs with the NTP server, which ultimately syncs with the atomic clock.

Devices also keep track of time


There are many reasons why our devices and computers need accurate time. For example, in banking, stock markets, and other financial enterprises, transactions must be performed in the proper order, and accurate timing is critical.

Our phones, tablets, cars, GPS systems and computers require precise time and date settings. I want the clock on the desktop of my computer to show the correct time. I want my local calendar to have reminders at the right time. The correct time also ensures that the cron and systemd jobs run at the right time.

Date and time are also important for logging, so it’s a bit easier to find certain logs based on date and time. For example, I once worked at DevOps (they didn’t call it that at that time) and set up an email system in North Carolina. We used to process over 20 million emails per day. Tracking e-mail through a series of servers or determining the exact sequence of events using log files on geographically dispersed hosts can be much easier if the computers are synchronized in time.

One time - many hours


Linux hosts must be aware that there is a system time and RTC time. RTC (Real Time Clock) is a bit strange and not very accurate name for a hardware clock.

The hardware clock runs continuously even when the computer is turned off using the battery on the system's motherboard. The main function of RTC is to store the time when the connection to the time server is unavailable. In those days when it was impossible to connect to the time server via the Internet, each computer had to have an accurate internal clock. Operating systems had to access RTC at boot time, and the user had to manually set the system time using the hardware BIOS configuration interface to make sure it was correct.

Hardware watches do not understand the concept of time zones; RTC only stores time, not the time zone or offset from UTC (Coordinated Universal Time, which is also known as GMT or Greenwich Mean Time). You can install RTC using the tool, which I will discuss later in this article.

System time is the time that the OS displays on the GUI clock on your desktop, in the output of the date command, in the timestamps of the logs. This also applies to the time files were created, modified, and opened.

The man for rtc page has a full description of RTC and the system clock.

What does NTP have?


Computers around the world use NTP (Network Time Protocol) to synchronize their time with a standard reference clock over the Internet using a hierarchy of NTP servers.The main time servers are located at level 1, and they are directly connected to various national time services at level 0 via satellite, radio or even modems via telephone lines. Time services at level 0 can be an atomic clock, a radio receiver that is tuned to the signals transmitted by the atomic clock, or a GPS receiver using high-precision clock signals transmitted by GPS satellites.

On the vast majority of reference servers, several thousand public NTP stratum 2 servers are open, which are available to everyone. Many organizations and users (including me) with a large number of hosts that require an NTP server prefer to install their own time servers, so only one local host calls stratum 2 or 3. Then they configure the remaining nodes on the network to use the local time server. In the case of my home network, this is a level 3 server.

Various NTP implementations


The initial implementation of NTP is ntpd. Then two newer ones joined her, chronyd and systemd-timesyncd. All three synchronize the local host time with the NTP time server. The systemd-timesyncd service is not as reliable as chronyd, but this is sufficient for most purposes. If RTC is not synchronized, it can gradually adjust the system time to synchronize with the NTP server when the local system time is slightly shifted. The systemd-timesync service cannot be used as a time server.

Chrony is an NTP implementation that contains two programs: the chronyd daemon and the command line interface called chronyc. Chrony has some features that in many cases are simply irreplaceable:

  • Chrony can synchronize with the time server much faster than the old ntpd service. This is good for laptops or desktop computers that do not work all the time.
  • It can compensate for clock frequency fluctuations, for example, when the host switches to sleep mode or enters sleep mode, or when the clock frequency changes due to a frequency jump that slows down the clock frequencies at low loads.
  • It solves time problems associated with unstable network connections or network congestion.
  • It adjusts network latency.
  • After the initial time synchronization, Chrony never stops the clock. This provides stable and consistent time intervals for many system services and applications.
  • Chrony can work even without a network connection. In this case, the local host or server can be updated manually.
  • Chrony can act as an NTP server.

Once again: NTP is a protocol that can be implemented on a Linux host using Chrony or systemd-timesyncd.

NTP, Chrony, and systemd-timesyncd RPMs are available in standard Fedora repositories. RPM systemd-udev is a kernel event manager that is installed by default in Fedora but is not required.

You can install all three and switch between them, but this will create an extra headache. So it’s better not to. Current releases of Fedora, CentOS, and RHEL have migrated to Chrony as a standard implementation, and they also have systemd-timesyncd. I believe that Chrony works well, provides a better interface than the NTP service, provides much more information and increases control, which system administrators will certainly enjoy.

Disabling NTP Services


Your host may already have the NTP service running. If so, you need to disable it before switching to something else. I had chronyd running, so I used the following commands to stop and disable it. Run the appropriate commands for any NTP daemon that you use on your host:

[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd Removed/etc/systemd/system/multi-user.target.wants/chronyd.service. [root@testvm1 ~]# 


Verify that the service is stopped and disabled:

[root@testvm1 ~]# systemctl status chronyd ● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:chronyd(8) man:chrony.conf(5) [root@testvm1 ~]# 

Check status before launch


The system clock synchronization status allows you to determine if the NTP service is running. Since you haven't started NTP yet, the timesync-status command will hint at this:

[root@testvm1 ~]# timedatectl timesync-status Failed to query server: Could not activate remote peer. 

A direct status request provides important information.For example, the timedatectl command with no argument or parameters executes the default status subcommand:

[root@testvm1 ~]# timedatectl status Local time: Fri 2020-05-15 08:43:10 EDT Universal time: Fri 2020-05-15 12:43:10 UTC RTC time: Fri 2020-05-15 08:43:08 Time zone: America/New_York (EDT, -0400) System clock synchronized: no NTP service: inactive RTC in local TZ: yes Warning: The system is configured to read the RTC time in the local time zone. This mode cannot be fully supported. It will create various problems with time zone changes and daylight saving time adjustments. The RTC time is never updated, it relies on external facilities to maintain it. If at all possible, use RTC in UTC by calling 'timedatectl set-local-rtc 0'. [root@testvm1 ~]# 

So you get the local time for your host, UTC time and RTC time. In this case, the system time is set to the America/New_York (TZ) time zone, the RTC is set to the time in the local time zone, and the NTP service is not active. RTC time began to deviate slightly from the system time. This is normal for systems whose clocks have not been synchronized. The amount of offset on the host depends on the time elapsed since the last system synchronization.

We also received a warning about using local time for RTC - this applies to changes in the time zone and daylight saving time settings. If the computer is turned off at the moment when it is necessary to make changes, the RTC time will not change. But for servers or other hosts that work around the clock, this is not a problem at all. In addition, any service that provides NTP time synchronization will adjust the host time at the initial start-up phase, so once the start is complete, the time will become correct again.

Setting the time zone


Usually you specify the time zone during the installation procedure, and you have no task to change it in the future. However, there are times when you need to change the time zone. There are several tools that can help. Linux uses time zone files to determine the local time zone of the host. These files are located in the /usr/share/zoneinfo directory. By default, for my time zone, the system writes this: /etc/localtime - >./usr/share/zoneinfo/America/New_York . But you don’t need to know such subtleties to change the time zone.

The main thing is to know the official name of the time zone for your location and the corresponding team. Say you want to change the time zone to Los Angeles:

[root@testvm2 ~]# timedatectl list-timezones | column <SNIP> America/La_Paz Europe/Budapest America/Lima Europe/Chisinau America/Los_Angeles Europe/Copenhagen America/Maceio Europe/Dublin America/Managua Europe/Gibraltar America/Manaus Europe/Helsinki <SNIP> 

Now you can set the time zone. I used the date command to check for changes, but you can also use timedatectl:

[root@testvm2 ~]# date Tue 19 May 2020 04:47:49 PM EDT [root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles [root@testvm2 ~]# date Tue 19 May 2020 01:48:23 PM PDT [root@testvm2 ~]# 

Now you can again change the time zone of your host to local time.

systemd-timesyncd


The systemd timesync daemon provides an NTP implementation that is easy to manage in the context of systemd. It is installed by default in Fedora and Ubuntu. However, it starts by default only in Ubuntu. I'm not sure about other distributions. You can check it out for yourself:

[root@testvm1 ~]# systemctl status systemd-timesyncd 

Configuring systemd-timesyncd


The configuration file for systemd-timesyncd is /etc/systemd/timesyncd.conf . This is a simple file with fewer options included than in the old NTP and chronyd services. Here is the contents of this file (without further changes) on my Fedora virtual machine:

# This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See timesyncd.conf(5) for details. [Time] #NTP= #FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org #RootDistanceMaxSec=5 #PollIntervalMinSec=32 #PollIntervalMaxSec=2048 

The only section it contains, apart from comments, is [Time]. All other lines are commented out. These are the default values, they do not need to be changed (unless you have a reason for this). If you do not have the NTP time server defined in the NTP=line, Fedora uses the Fedora backup time server by default. I usually add my time server:

NTP=myntpserver 

Running timesync


You can start and make systemd-timesyncd active like this:

[root@testvm2 ~]# systemctl enable systemd-timesyncd.service Created symlink/etc/systemd/system/dbus-org.freedesktop.timesync1.service →/usr/lib/systemd/system/systemd-timesyncd.service. Created symlink/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service →/usr/lib/systemd/system/systemd-timesyncd.service. [root@testvm2 ~]# systemctl start systemd-timesyncd.service [root@testvm2 ~]# 

Installing the hardware clock


Here's what the situation looks like after running timesyncd:

[root@testvm2 systemd]# timedatectl Local time: Sat 2020-05-16 14:34:54 EDT Universal time: Sat 2020-05-16 18:34:54 UTC RTC time: Sat 2020-05-16 14:34:53 Time zone: America/New_York (EDT, -0400) System clock synchronized: yes NTP service: active RTC in local TZ: no 

Initially, the difference between RTC and local time (EDT) does not exceed a second, and the discrepancy increases by a couple of seconds over the next few days. Since there is no concept of time zones in RTC, the timedatectl command must perform a comparison to determine the desired time zone. If the RTC does not exactly match the local time, then it does not match the local time zone.

Looking for more information, I checked the status of systemd-timesync and found this:

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago Docs: man:systemd-timesyncd.service(8) Main PID: 822 (systemd-timesyn) Status: "Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org)." Tasks: 2 (limit: 10365) Memory: 2.8M CPU: 476ms CGroup:/system.slice/systemd-timesyncd.service └─822/usr/lib/systemd/systemd-timesyncd May 16 09:57:24 testvm2.both.org systemd[1]: Starting Network Time Synchronization... May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization. May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org). [root@testvm2 systemd]# 

Pay attention to the log message, which says that the system time is not set or reset back. The Timesync service sets the system time based on a timestamp. Timestamps are supported by the timesync daemon and are created upon each successful synchronization.

The timedatectl command is not able to take the value of the hardware clock from the system clock. She can set the time and date only from the value entered on the command line. You can set RTC to the same value as the system time using the hwclock command:

[root@testvm2 ~]#/sbin/hwclock --systohc --localtime [root@testvm2 ~]# timedatectl Local time: Mon 2020-05-18 13:56:46 EDT Universal time: Mon 2020-05-18 17:56:46 UTC RTC time: Mon 2020-05-18 13:56:46 Time zone: America/New_York (EDT, -0400) System clock synchronized: yes NTP service: active RTC in local TZ: yes 

The --localtime option indicates that the hardware clock shows local time, not UTC.

Why do you need RTC at all?


Any NTP implementation will set the system clock at startup. And then why RTC? This is not entirely true: this will only happen if you have a network connection to a time server. However, many systems do not have constant access to a network connection, so the hardware clock is useful for Linux to set the system time based on them. This is better than setting the time manually, even if it may deviate from real time.

Conclusion


This article covers some tools for managing date, time, and time zones. The systemd-timesyncd tool provides an NTP client that can synchronize time on a local host with an NTP server. However, systemd-timesyncd does not provide a server service, so if you need an NTP server on your network, you must use something else - for example, Chrony, to work as a server.

I prefer to have a single implementation for any services on my network, so I use Chrony. If you do not need a local NTP server or if you do not mind using Chrony as a server and systemd-timesyncd as an SNTP client. After all, there is no need to use the additional features of Chrony as a client, if you are satisfied with the functionality of systemd-timesyncd.

One more note: you are not required to use systemd tools to implement NTP. You can use the old version of ntpd, Chrony, or another NTP implementation. After all, systemd consists of a large number of services; many of them are optional, so you can turn them off and use something else instead. This is not a huge monolithic monster. You may not like systemd or parts of it, but you must make an informed decision.

I like the NTP implementation in systemd, but I prefer Chrony because it suits my needs better. This is Linux, baby -)



As advertising


VDSina offers servers for any tasks , a huge selection of operating systems for automatic installation, it is possible to install any OS from your own ISO , convenient own control panel and daily payment. Recall that we have eternal servers that are definitely timeless;)

ITKarma picture.

Source