chronyd服务未启动导致时间无法自动同步，必须手动启用并设为开机自启；配置需至少3个国内NTP源并启用iburst；硬件时钟需用sudo hwclock --systohc更新；偏差超1000秒时须执行sudo chronyc makestep并配置makestep 1 -1。

chronyd 服务没启动，时间根本不会自动纠正

很多用户以为装了 chrony 就万事大吉，结果 chronyd 服务压根没跑。系统不会主动同步，timedatectl status 里 “NTP service” 显示 inactive，或者 “System clock synchronized” 一直是 no。

必须手动启动并设为开机自启：

• sudo systemctl start chronyd
• sudo systemctl enable chronyd
• 再用 systemctl status chronyd --no-pager 确认状态是 active (running)

CentOS/RHEL 8+ 和 Ubuntu 20.04+ 默认启用 chronyd，但旧版本或最小化安装常处于 disabled 状态。别跳过这步，否则所有后续配置都无效。

配置文件里只写一个 server，同步失败率极高

/etc/chrony/chrony.conf 中如果只配 server ntp.aliyun.com iburst 一行，一旦该服务器不可达或响应超时，chronyd 会直接放弃同步，chronyc sources -v 输出可能全是 ^? （未响应）。

正确做法是至少配 3 个独立源，并启用 iburst 加速初始同步：

onewo-rtlinux

Linux 实时编程助手。生成、审查并修改用于周期性控制任务和中断驱动程序的 C 代码。强制实施实时调度策略。

下载

• 清空或注释掉默认的 pool 行（某些发行版自带的 pool 域名解析不稳定）
• 改用明确 IP 或可靠域名，例如：
  server ntp.ntsc.ac.cn iburst
server ntp1.aliyun.com iburst
server time.pool.org iburst
• 保存后必须执行 sudo systemctl restart chronyd，reload 不生效

硬件时钟（RTC）长期不准，重启后时间又偏移

即使 chronyd 每天都在校正系统时钟，若硬件时钟本身严重偏差（比如快 5 分钟），下次开机时内核仍会从 RTC 读取错误时间作为起点，导致“刚启动就偏了”。

这不是同步服务的问题，而是 RTC 未被更新：

• 确认系统时钟已同步准确（timedatectl 显示 System clock synchronized: yes）
• 运行 sudo hwclock --systohc，把当前正确的系统时间写入硬件时钟
• 注意：不要反向执行 hwclock --hctosys，除非你确定 RTC 是准的——现实中它几乎总是不准的
• 可加到 cron 定期执行（如每周一次），但首次手动执行不可省

时间偏差过大时，chronyd 默认拒绝同步

chronyd 出于安全考虑，默认对 >1000 秒（约 16 分钟）的偏差会拒绝调整，日志中出现 step threshold exceeded。此时 chronyc makestep 是唯一解法。

分两步操作：

• 先临时允许大步跳变：sudo chronyc makestep（立即生效，无需重启服务）
• 再确保配置文件中有 makestep 1 -1（表示对任意偏差都允许一步校正），否则下次重启仍会卡住
• 修改后 reload：sudo chronyc reload 或重启服务

这个参数容易被忽略，尤其在虚拟机克隆、镜像恢复或长时间断电后首次启动时，偏差常超阈值。