Most people keep track of time. We wake up on time to perform our morning rituals, head to work, take lunch breaks, meet project deadlines, celebrate birthdays and holidays, board flights, and so on.
Moreover, some of us are obsessed with time. My watch is powered by solar energy and gets the accurate time from the National Institute of Standards and Technology () in Fort Collins, Colorado, via a longwave radio station. Time signals are synchronized with atomic clocks, also located in Fort Collins. My Fitbit syncs with my phone, which in turn syncs with the server , which ultimately syncs with atomic clocks.
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 occur in the correct order, making precise timing sequences critically important.
Our phones, tablets, cars, GPS systems, and computers require accurate time and date settings. I want the clock on my computer desktop to display the correct time. I also want reminders in my local calendar to appear at the right time. Accurate time ensures that cron jobs and systemd tasks run when they are supposed to.
The date and time are also important for logging, making it easier to find specific logs based on date and time. For instance, once I was working in DevOps (though it wasn't called that at the time) and setting up an email system in North Carolina. We used to handle over 20 million emails a day. Tracking emails across a series of servers or determining the exact sequence of events using log files on geographically dispersed hosts can be much simpler if the relevant computers are time-synchronized.
There is one time — but many clocks.
Linux hosts need to consider that there is system time and RTC time. RTC (Real-Time Clock) is a somewhat strange and not very accurate name for hardware clocks.
Hardware clocks run continuously, even when the computer is turned off, using a battery on the motherboard. The main function of the RTC is to keep track of time when the connection to the time server is unavailable. In times when it was not possible to connect to a time server over the internet, every computer needed to have accurate internal clocks. Operating systems had to access the RTC during boot-up, and users had to manually set the system time using the BIOS configuration hardware interface to ensure it was correct.
Hardware clocks do not understand the concept of time zones; the RTC only holds the time, not the time zone or offset from UTC (Coordinated Universal Time, also known as GMT or Greenwich Mean Time). You can set the RTC using a tool that I will describe later in this article.
System time is the time displayed by the OS on the GUI clock on your desktop, in the output of the date command, and in log timestamps. It also refers to the time of creation, modification, and opening of files.
On the page there is a complete description of the RTC and system clocks.
What about NTP?
Computers around the world use NTP (Network Time Protocol) to synchronize their time with standard reference clocks over the internet through a hierarchy of NTP servers. The primary time servers are at level 1, and they are directly connected to various national time services at level 0 via satellite, radio, or even modems over telephone lines. Level 0 time services can be atomic clocks, a radio receiver tuned to signals transmitted by atomic clocks, or a GPS receiver using highly accurate time signals transmitted by GPS satellites.
On the vast majority of reference servers, several thousand public NTP stratum 2 servers are open and available to everyone. Many organizations and users (including myself) with a large number of hosts requiring an NTP server prefer to set up their own time servers so that only one local host queries stratum 2 or 3. They then configure the remaining nodes in the network to use the local time server. In the case of my home network, this is a stratum 3 server.
Different Implementations of NTP
The original implementation of NTP is ntpd. Then two newer ones joined it, chronyd and systemd-timesyncd. All three synchronize the time of the local host with the NTP time server. The systemd-timesyncd service is not as reliable as chronyd, but it is sufficient for most purposes. If the RTC is not synchronized, it can gradually adjust the system time to synchronize with the NTP server when the local system time drifts slightly. The systemd-timesync service cannot be used as a time server.
is an NTP implementation that includes two programs: the chronyd daemon and a command-line interface called chronyc. Chrony has some features that are simply indispensable in many cases:
- Chrony can synchronize with time servers much faster than the old ntpd service. This is beneficial for laptops or desktop computers that are not always running.
- It can compensate for clock frequency fluctuations, such as when a host goes into sleep mode or wakes up, or when the clock frequency changes due to sudden frequency shifts that slow down the clock under low loads.
- It addresses time issues related to unstable network connections or network overload.
- It adjusts for network delays.
- 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 operate even without an internet 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 RPM packages are available in the standard Fedora repositories. The RPM systemd-udev is the kernel event manager that is installed by default in Fedora but is not mandatory for use.
You can install all three and switch between them, but that would create unnecessary headaches. It's better not to. Modern releases of Fedora, CentOS, and RHEL have switched to Chrony as the standard implementation, and they also have systemd-timesyncd. I believe that Chrony works well, offers a better interface than the NTP service, provides much more information, and enhances control, which will definitely appeal to system administrators.
Disabling NTP services
There may already be an NTP service running on your host. 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 you are using on your host:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Check 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 ~]#Checking status before starting
The system clock synchronization status allows you to determine whether the NTP service is running. Since you have not 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 query provides important information. For example, the timedatectl command without arguments or parameters executes the status subcommand by default:
[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 ~]#This will give you 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 local time, and the NTP service is inactive. The RTC time has started to drift slightly from the system time. This is normal for systems with unsynchronized clocks. The degree of drift on the host depends on the time elapsed since the last system synchronization.
We also received a warning about using local time for the RTC—this pertains to time zone changes and daylight saving time settings. If the computer is turned off when changes need to be made, the RTC time will not change. However, for servers or other hosts that run 24/7, this is generally not an issue. Additionally, any service providing NTP time synchronization will correct the host time even at the initial boot stage, so time will become accurate again after boot completion.
Setting the Time Zone
Typically, you specify the time zone during the installation process, and there's no need to change it thereafter. However, there are occasions when it's necessary to change the time zone. There are several tools that can assist. To determine the local time zone, Linux uses time zone files. These files are located in the directory /usr/share/zoneinfo. By default, my system writes this for my time zone: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. But you don't need to know these details to change the time zone.
The main thing is to know the official name of the time zone for your location and the corresponding command. For example, if you want to change the time zone to Los Angeles:
[root@testvm2 ~]# timedatectl list-timezones | column
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/HelsinkiYou can now set the timezone. I used the date command to check the 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 ~]#You can now change your host's timezone to local time again.
systemd-timesyncd
The systemd timesync daemon provides an NTP implementation that is easy to manage within systemd. It is installed by default on Fedora and Ubuntu. However, it is only started by default on Ubuntu. I'm not sure about other distributions. You can check for yourself:
[root@testvm1 ~]# systemctl status systemd-timesyncdConfiguring systemd-timesyncd
The configuration file for systemd-timesyncd is /etc/systemd/timesyncd.conf. It is a simple file with fewer options enabled than older NTP and chronyd services. Here is the content of this file (without additional 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=2048The only section it contains, apart from comments, is [Time]. All other lines are commented out. These are default values that do not need to be changed (unless you have reasons to do so). If you do not have an NTP time server specified in the NTP = line, the default is to use the Fedora fallback time server. I usually add my time server:
NTP=myntpserverStarting timesync
You can start and enable systemd-timesyncd 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 ~]#Setting Hardware Clock
Here is what the situation looks like after starting 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 RTC has no concept of time zones, the timedatectl command must perform a comparison to determine the necessary time zone. If the RTC time does not exactly match the local time, then it does not match the local time zone either.
In search of additional information, I checked the status of systemd-timesync and found the following:
[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]#Note the log message indicating that the system time is unset or has jumped backwards. The Timesync service sets the system time based on the timestamp. The timestamps are maintained by the timesync daemon and created during each successful synchronization.
The timedatectl command does not have the capability to take the hardware clock value from the system clock. It can only set the time and date based on the value entered in the command line. You can set the 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: yesThe --localtime option indicates that the hardware clock shows local time rather than UTC.
Why do you even need RTC?
Any NTP implementation will set the system clock at startup. So why do we need an RTC? It's not that simple: 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 hardware clocks are 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 the actual time.
Conclusion
This article discusses some tools for managing date, time, and time zones. The systemd-timesyncd tool provides an NTP client that can synchronize the time on the local host with an NTP server. However, systemd-timesyncd does not provide a server service, so if you need an NTP server in your network, you have to use something else—like Chrony—to act as a server.
I prefer to have a single implementation for any services in my network, so I use Chrony. If you don't need a local NTP server or if you're okay with using Chrony as a server and systemd-timesyncd as an SNTP client. After all, there's no need to use the extra features of Chrony as a client if you're satisfied with the functionality of systemd-timesyncd.
Another note: you are not obligated to use systemd tools for NTP implementation. You can use an older version of ntpd, Chrony, or another NTP implementation. Systemd consists of many services; many of them are optional, so they can be disabled and replaced with something else. It's not a huge monolithic monster. You might dislike systemd or its components, but you should make an informed decision.
I like the NTP implementation in systemd, but I prefer Chrony because it better meets my needs. It's Linux, baby -)
Advertising
VDSina offers , a huge selection of operating systems for automatic installation, and there is an option to install any OS from your own with a user-friendly proprietary development, and daily payment options. Remember, we have eternal servers that are truly timeless 😉
Source: habr.com
