chrony的makestep未生效是因为默认禁用跳变，需显式配置且满足偏差超限、已完成初始同步两个条件；常见原因包括未重启服务、启动时网络不可达导致卡在initializing状态。
chrony 的 makestep 为什么没生效？
默认情况下 chrony 不会主动跳变系统时间，即使偏差远超阈值——这是设计使然，防止意外跳变破坏日志、数据库事务等依赖单调时间的场景。只有显式启用 makestep 才可能触发跳变，且需满足两个条件：偏差超过设定阈值，且 chronyd 已完成初始同步（即进入“synchronized”状态）。
常见错误是只在 /etc/chrony.conf 中写了 makestep 1.0 -1，但没重启服务，或 chronyd 启动时网络未就绪、NTP 源不可达，导致始终卡在“initializing”状态，makestep 根本不触发。
-
makestep的第二参数为负数（如-1）表示“对所有启动阶段生效”，但仅对首次同步有效；后续运行中若时间偏差再次超限，仍需手动干预或配合chronyc makestep - 检查状态用
chronyc tracking，确认输出中Leap status是Normal且System time行有数值，才说明已同步 - 若 chronyd 启动时网络未通，可加
makestep 1.0 0（0 表示仅对启动后首次同步生效），再配合network-manager或systemd-networkd的启动顺序控制
timekeeping watchdog expired 错误的真实含义
这不是 chrony 报的错，而是内核在检测到长时间未更新 clock_gettime(CLOCK_MONOTONIC) 或 CLOCK_REALTIME 时触发的 panic 或 warning，常见于虚拟机暂停后恢复、CPU 长时间离线、或系统时间被暴力修改（如直接写 /dev/rtc）导致内核 timekeeper 逻辑失步。此时 chrony 可能还在跑，但内核已拒绝更新时间。
该错误出现后，chronyc tracking 常显示 Leap status: Not synchronised，且 chronyc sources -v 中延迟异常高，因为 chronyd 尝试校正时被内核拦截。
