systemd-timesyncd 默认启用但未必运行，需检查状态、配置NTP服务器、排除chronyd/ntpd冲突，并验证RTC同步。
systemd-timesyncd 服务是否启用并运行
linux 发行版（尤其是 debian/ubuntu/centos 8+）默认用 systemd-timesyncd 做轻量级 NTP 同步，但它默认可能没启动，或被 ntpd/chronyd 冲突停用。
- 检查状态：
systemctl status systemd-timesyncd—— 若显示inactive (dead)或failed，说明没生效 - 若已启用但未同步，看日志：
journalctl -u systemd-timesyncd --since "1 hour ago"，常见错误如Failed to resolve server（dns 不通）或No suitable source found（NTP 服务器不可达） - 确认配置文件
/etc/systemd/timesyncd.conf中NTP=行是否注释；未注释时建议设为可信源，例如：NTP=ntp.aliyun.com ntp1.aliyun.com - 改完需重启：
sudo systemctl restart systemd-timesyncd，再等 30–60 秒后执行timedatectl status查看System clock synchronized: yes
timedatectl 显示的同步状态是否可信
timedatectl status 输出里 System clock synchronized: yes 并不绝对可靠——它只反映最近一次同步尝试是否成功，不保证持续有效，也不代表时间偏差在可接受范围内。
- 真正要看的是
Network time on: yes（说明启用了网络校时）和RTC in local TZ: no（推荐值，避免双系统时间混乱） - 关键字段是
System clock synchronized:后面的yes/no，但必须结合timedatectl timesync-status看实际偏移：Root dispersion:应 Offset: 绝对值最好 - 如果
Offset:持续 > 1s 且波动大，可能是防火墙阻断 udp 123 端口，或本地时钟漂移率过高（adjtimex -p | grep "frequency"查看 ppm 值，> ±500 ppm 就该怀疑硬件时钟了）
chronyd 或 ntpd 是否与 systemd-timesyncd 冲突
多个时间服务共存会导致互相抢占、校时失败甚至时间跳变。常见于手动装过 chrony 或 ntp 包的系统。
- 查活跃服务：
systemctl list-units --type=service | grep -E "(chrony|ntp|timesync)" - 若
chronyd.service或ntpd.service是active (running)，而systemd-timesyncd也在跑，必须停掉其中一个 —— 推荐保留chronyd（功能更全），禁用systemd-timesyncd：sudo systemctl stop systemd-timesyncd && sudo systemctl disable systemd-timesyncd - chronyd 配置重点看
/etc/chrony/chrony.conf中pool或server行是否可达，以及makestep是否启用（允许大步长校正，默认关） - 校验 chronyd 同步质量：
chronyc tracking（看Offset和Skew），chronyc sources -v（看哪些源在用、延迟如何）
硬件时钟（RTC）与系统时钟是否双向同步
即使网络时间同步正常，若 RTC（主板电池供电的实时时钟）长期不准，重启后系统仍会回到错误时间 —— 尤其在虚拟机或无网络环境启动时。
- 写系统时间到 RTC：
sudo hwclock --systohc（注意：仅在确认系统时间已校准后执行） - 读 RTC 时间验证：
hwclock --show，对比date输出，差值应 - 检查 RTC 时区设置：
timedatectl show --Property=LocalRTC，返回LocalRTC=no才正确（即 RTC 存 UTC 时间）；若为yes，需执行sudo timedatectl set-local-rtc 0 - VM 场景要额外注意：某些虚拟化平台（如 vmware/VirtualBox）会自动同步客户机时间，此时应关闭
systemd-timesyncd或 chronyd，并在宿主机侧统一管理时间
时间不同步问题最常卡在“以为同步了，其实只是上次成功过”，或者“多个服务抢着调时间却谁都没调好”。动手前先用 timedatectl timesync-status 和 chronyc tracking（或对应工具）看真实偏移，比反复重启服务有用得多。