根本原因是systemd-timesyncd虽启用但未开启持续同步，需执行timedatectl set-ntp true，并确保配置文件中NTP=行已启用且服务器可达，同时排除chronyd/ntpd冲突、DNS解析失败或防火墙拦截UDP 123端口。
为什么 systemd-timesyncd 启动了却没同步时间？
常见现象是 timedatectl status 显示 System clock synchronized: no，即使 systemd-timesyncd 服务已启用并运行。根本原因通常是默认未启用 NTP 同步（systemd-timesyncd 默认只做一次初始同步，且需手动开启持续同步）。
- 检查是否真正启用同步：
timedatectl set-ntp true—— 这会启动systemd-timesyncd并打开持续轮询 - 确认配置文件
/etc/systemd/timesyncd.conf中NTP=行未被注释，且至少填一个可用服务器，例如：NTP=ntp.aliyun.com pool.ntp.org - 注意：若系统启用了
chronyd或ntpd，systemd-timesyncd会被自动禁用，timedatectl仍可能显示 “NTP enabled: yes”，但实际由其他服务接管
如何验证当前生效的时钟源和同步状态？
不能只看服务是否 running，得查实际连接和偏移。最直接的方式是结合两个命令：
-
timedatectl status：关注System clock synchronized和NTP service字段（显示 active/inactive） -
journalctl -u systemd-timesyncd --since "1 hour ago" | grep -i "update\|error"：查最近是否成功收到服务器响应；若出现Failed to parse response或No such file or directory，大概率是防火墙拦截 UDP 123 端口或 DNS 解析失败 - 更底层验证：
ntpq -p仅对chronyd有效；systemd-timesyncd不提供类似 CLI 工具，只能靠日志 +timedatectl
手动触发一次时间校准但不启用持续同步？
某些嵌入式或受限环境不允许长期 NTP 连接，只需开机/唤醒后强制校准一次。这时别用 timedatectl set-ntp true，而是：
- 确保
systemd-timesyncd正在运行：sudo systemctl start systemd-timesyncd - 执行单次同步：
sudo systemctl restart systemd-timesyncd（重启会触发一次立即查询） - 等待几秒后运行
timedatectl查看System clock synchronized是否变为yes；若超时，可加--no-block避免卡住脚本 - 注意：
systemd-timesyncd的单次行为不可靠——它可能因超时直接放弃，且无返回码提示失败，必须依赖后续timedatectl状态判断
使用 chronyd 替代时要注意哪些兼容性陷阱？
chronyd 更适合虚拟机、断网频繁或高精度场景，但和 systemd-timesyncd 冲突明显：
- 安装
chrony包后，systemd-timesyncd会自动被 mask（sudo systemctl disable --now systemd-timesyncd），但timedatectl可能缓存旧状态，需重启或运行sudo systemctl daemon-reload -
chronyd默认监听所有接口，如需限制，修改/etc/chrony.conf中的bindcmdaddress和bindaddress - 关键区别：chronyd 支持硬件时钟（RTC）写入（
rtcsync指令），而systemd-timesyncd不操作 RTC；若需关机后仍保持准确，必须用 chronyd 或手动hwclock --systohc
resolv.conf 不可用或 systemd-resolved 未就绪，systemd-timesyncd 就会静默失败，日志里只显示 “Failed to resolve” 而没有明确报错来源。 
