chronyd 同步后重启时间偏移是因 RTC 未同步所致；需启用 rtcsync 并用 hwclock 首次校准，硬件老化、虚拟机配置或容器环境限制亦会导致该问题。
chronyd 同步后系统时间正确，但重启后时间严重偏移
这是典型的 RTC（Real-Time Clock）未与系统时钟同步导致的问题。chronyd 默认只维护系统时钟（software clock），不会自动写回硬件时钟（CMOS/RTC），所以断电重启后 BIOS 仍按旧的硬件时间启动，造成“时间倒退”或“快进”。
关键判断点：timedatectl status 中若显示 RTC time: … 与 Local time: … 相差很大（尤其跨天），且 RTC in local TZ: no，基本可锁定为 RTC 同步缺失。
- chronyd 不会默认启用硬件时钟写入，需显式配置
rtcsync或手动触发 - 部分主板 RTC 晶振老化或电池电压不足，会导致写入后仍持续漂移（每天 ±1~5 秒以上）
- 虚拟机环境下，
/dev/rtc可能不可用或被宿主机接管，rtcsync无效
启用 chronyd 的 rtcsync 并验证是否生效
rtcsync 是 chronyd 内置机制，它让内核周期性（约每秒一次）将系统时钟同步到 RTC，比传统 hwclock --systohc 更平滑、更及时。但必须确认 chronyd 配置已启用且服务重载成功。
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 编辑
/etc/chrony.conf，确保存在且未被注释：rtcsync - 重启服务：
systemctl restart chronyd - 检查是否加载成功：
chronyc tracking | grep 'RTC'—— 若输出含RTC is synced表示已启用 - 注意：仅启用
rtcsync不代表 RTC 当前就准确，它只负责“持续同步”，初始偏差仍需人工校准
首次校准 RTC：用 hwclock 手动写入当前系统时间
即使启用了 rtcsync，若 RTC 初始偏差过大（如几分钟），chronyd 不会主动修正——它只做微调。必须先用 hwclock 强制写入一次。
- 确保系统时间已由 chronyd 稳定同步（
chronyc tracking显示Leap status: Normal且System time偏差 - 执行：
hwclock --systohc --utc（推荐 UTC 模式；若 BIOS 设为本地时间，则用--localtime，但易引发时区混乱） - 验证写入结果：
hwclock --show输出应与date接近（误差 - 注意：某些 ARM 设备或嵌入式平台无标准
/dev/rtc，hwclock会报错Cannot access the Hardware Clock via any known method，此时需查内核是否启用CONFIG_RTC_CLASS
排查 RTC 漂移源头：电池、晶振、虚拟化干扰
如果完成上述步骤后，重启仍偏移 > 2 秒/天，问题大概率不在 chronyd 配置，而在硬件或运行环境。
- 物理服务器：拆机检查 CMOS 电池电压（正常 ≥ 2.8V），低于 2.6V 时 RTC 晶振停振或频率失稳，换新电池后需重新校准
- 老旧主板（如 Intel 6-series 芯片组）：存在已知 RTC 计时不稳 bug，升级 BIOS 可缓解
- KVM/QEMU 虚拟机：确认宿主机已启用
clock=host或rtc_clock=host，且客户机未挂载qemu-ga干扰时间同步 - 容器环境：/dev/rtc 默认不挂载，
rtcsync失效；若需精确时间，应依赖宿主机 chronyd + NTP 客户端，而非尝试操作 RTC
RTC 漂移本身不破坏 chronyd 运行逻辑，但它会让“重启后的时间起点”不可控——这个起点一旦偏了，后续所有同步都只是在错误基础上修修补补。
