3 Basic Commands and Simple Shell Scripts Once you have your first Red Hat Enterprise Linux rhel
Download 1.85 Mb. View original pdf
|
- Navigate this page:
- Internet Protocol (IP
- Long-term average (LTA
| NTP client In RHEL 9, chrony acts as both the server (when enabled) and the client (via the chronyc command, and it comes with some features that make it suitable for current hardware and user needs, such as fluctuating networks (laptop is suspended/resumed or flaky connections). One interesting feature is that chrony does not step the clock after its initial sync, which means that the time doesn’t jump. Instead, the system clock runs faster or slower so that, after a period of time, it will be in sync with the reference clock it’s using. This makes the time to be a continuum from the operating system and application’s point of view the seconds are going faster or slower than what they should be if compared against a clock until they match the reference clock. chrony is configured via /etc/chrony.conf and acts as a client, so it connects to servers to check if they’re eligible to be the time source. The main difference between the traditional server directive and the pool is that the latter can receive several entries while the former only uses one. It is possible to have several servers and pools because, in effect, the servers will be added to the list of possible sources once duplicates have been removed. For pool or server directives, there are several options available (described in man chrony.conf), such as iburst, which enables faster checks so that they can quickly transition to a synchronized status. The actual sources for time can be checked with chronyc sources, as illustrated in the following screenshot: Figure 4.5 – chronyc sources output Learning about time synchronization with chrony and NTP 119 As we can see, we know what the status is for each server based on the first column (Mas outlined here ^: This is a server =: This is a peer In the second column (S, we can seethe different statuses for each entry, as follows *: This is our current synchronized server +: This is another acceptable time source ?: This is used to indicate sources that have lost network connectivity x This server is considered a false ticker (its time is considered inconsistent compared to other sources : A source that has a high variability (it also appears during daemon startup) So, we can see that our system is connected to a server that is considering the reference at ts1.sct.de, which is a stratum 2 server. More detailed information can be checked via the chronyc tracking command, as illustrated in the following screenshot: Figure 4.6 – chronyc tracking output Tools for Regular Operations 120 This provides more detailed information about our clock and our reference clock. Each field in the preceding screenshot has the following meaning Reference ID ID and name/Internet Protocol (IP) address of the server that the system has synchronized Stratum Our stratum level. In this example, our synchronized server is a stratum 3 clock Ref time (UTC The last time the reference was processed System time When running in normal mode (without time skip, this references how faraway or behind the system is from the reference clock Last offset Estimated offset on the last clock update. If it’s positive, this indicates that our local time was ahead of our source RMS offset Long-term average (LTA) of the offset value Frequency This is the rate at which the system clock would be wrong if chronyd does not fix it, expressed in Download 1.85 Mb. Share with your friends:
|