返回文章列表文章索引阅读全文
STARBLOG / 阅读手记
系统配置

Server time drift, how to enable Linux NTP auto-sync

This article documents the author's experience discovering a time drift issue during server maintenance and the entire process of troubleshooting and resolving it by enabling NTP synchronization and using tools like Chrony. The article emphasizes the importance of NTP synchronization, introduces troubleshooting approaches and the use of efficient tools, as well as how to synchronize the hardware clock (RTC), providing a solution for precise server time synchronization.

曦远 (DealiAxy)约 15 分钟
目录12 个章节

Foreword

In our daily server operations, we often assume that the server's time is accurate. However, a recent casual date query made me realize—the server time had silently drifted...

This article documents the entire troubleshooting and resolution process, hoping to help friends encountering similar issues, and also to leave behind a systematic note for my own growth.

Discovering the Issue

I was recently developing the access analysis feature for StarBlog, but I noticed that the recorded logs seemed to have incorrect timestamps.

So I logged into the server and ran the date command, finding that the current time had a noticeable discrepancy with the actual Beijing time.

[deali@server ~]# date
Sun Apr 27 14:40:53 CST 2025

Although the time difference was not large, for a server that requires precise time logging, even a few minutes of error can lead to a series of problems such as misaligned log timestamps, abnormal scheduled tasks, and SSL verification failures.

Initial Troubleshooting

To further confirm the issue, under the guidance of the model expert, I used the timedatectl status command for investigation:

[deali@server ~]# timedatectl status
      Local time: Sun 2025-04-27 14:40:53 CST
  Universal time: Sun 2025-04-27 06:40:53 UTC
        RTC time: Sun 2025-04-27 06:50:29
       Time zone: Asia/Shanghai (CST, +0800)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

As we can see, although the time zone is set correctly (Asia/Shanghai), NTP is not enabled (NTP enabled: no), and it is also not synchronized (NTP synchronized: no).

This means the server time is entirely dependent on the system's own operation, which will inevitably lead to drift over time.

🔎 Fun Fact: NTP (Network Time Protocol) is a protocol used to synchronize time between network devices, keeping system time synchronized with Coordinated Universal Time (UTC), which is crucial.

Try Enabling NTP Synchronization

So, I tried enabling NTP synchronization via timedatectl:

sudo timedatectl set-ntp true

Checking the status again:

[deali@server ~]# timedatectl status
     NTP enabled: yes
NTP synchronized: no

Although NTP was successfully enabled (enabled: yes), the synchronization status remained no.

For a moment, I thought I saw a glimmer of hope, but it was nearly drenched by the rain of reality. 🌧️

This indicates that while the server has the NTP synchronization switch turned on, it has not successfully synchronized. Possible reasons include:

  • The server lacks the corresponding NTP client service;
  • The network cannot access the default time server;
  • More time may be needed to wait for the initial synchronization (though this is not reliable).

Using Chrony

For fast and stable time synchronization, I chose to install a lightweight and efficient NTP client — chrony.

Installation

sudo yum install chrony -y
sudo systemctl enable chronyd
sudo systemctl start chronyd

Instant Time Synchronization

sudo chronyc makestep

After execution, the system time will be instantly and accurately aligned—no waiting required!

Configure Domestic NTP Sources

Edit /etc/chrony.conf and replace the default servers with domestic sources (国内源)

server ntp.aliyun.com iburst
server ntp1.aliyun.com iburst
server cn.pool.ntp.org iburst

After saving, restart chronyd:

sudo systemctl restart chronyd

Verify Synchronization Status

chronyc tracking

The output shows detailed information including the reference time source (参考时间源), synchronization status (stratum), and other details.

Additionally, timedatectl status displays:

NTP enabled: yes
NTP synchronized: yes

At this point, the system time synchronization issue is basically resolved.

Synchronizing Hardware Clock (RTC)

Although the system time has been synchronized, checking reveals that the hardware clock (RTC) is still inconsistent with the system time.

If not synchronized promptly, time discrepancies may reappear the next time the server restarts.

You can use a command to sync the system time to the RTC:

sudo hwclock --systohc

After the synchronization is complete, verify:

hwclock --show

Confirm that the hardware clock is consistent with the system time, ensuring accurate time from the moment the machine boots up.

Summary

Through this troubleshooting and resolution process, I gained the following insights:

  • Importance of NTP Synchronization
    System time drift can trigger a chain of reactions; it is essential to ensure accurate server time synchronization.

  • Significance of a Systematic Troubleshooting Approach
    Starting from surface-level issues, use appropriate tools (like timedatectl) to methodically investigate, avoiding blind actions.

  • Leverage Efficient Tools (Chrony)
    Compared to the traditional ntpd, chrony is lighter, more flexible, and faster, making it ideal for modern server environments.

  • Systemic Growth from Minor Issues
    Each troubleshooting effort, though seemingly trivial, actually hones your problem analysis capabilities and system operations skills.

🚀 If operations is a long-distance race, then every problem solved is a small step steadily moving toward professionalism.

I hope this experience can also help you on your path to growth.

References

_EOF_

Server time drift, how to enable Linux NTP auto-sync

本文作者:
程序设计实验室
版权声明:
本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!

相关文章

讨论

共 0 条

良言一句三冬暖,恶语伤人六月寒。

加载评论中…