chrony 没有 timekeeping watchdog 模块，所谓 watchdog 通常指内核对 chronyd 卡死或时钟跳变过大的误判；真正影响时间校正的是 makestep 配置，如 makestep 1.0 -1 允许任意时刻对 ≥1 秒偏移跳变，需重启服务生效，且须注意跳变对日志、TLS 等依赖系统时间的应用的影响。
chrony 的 timekeeping watchdog 是什么
chrony 本身没有叫 timekeeping watchdog 的内置模块，这个说法通常指 Linux 内核的 watchdog 子系统（如 softlockup_panic 或 hardlockup_panic）误判 chronyd 长时间未响应，或用户把 chronyd 进程卡死、时钟跳变过大触发内核时钟监控告警。真正影响 chrony 行为的是 makestep 和 rtcsync 等配置项，以及系统时钟偏移是否超过 makestep 阈值。
超时后 chrony 不自动校正？检查 makestep 配置
chronyd 默认不会在启动或运行中“暴力”跳变系统时间，除非显式启用 makestep。如果时钟偏差已超 1 秒但没同步，大概率是 makestep 被禁用或阈值设得太高。
-
makestep 1.0 -1：允许在任意时间点对 ≥1.0 秒的偏移执行跳变（推荐用于虚拟机或经常休眠的设备） -
makestep 0.128 3：只在前 3 秒内对 ≥128ms 偏移跳变（默认值，较保守） - 修改
/etc/chrony.conf后必须重启服务：sudo systemctl restart chronyd - 验证是否生效：
chronyc tracking查看Leap status和System time偏移；chronyc makestep手动触发一次跳变（需 root）
burst 模式不是 chrony 命令，正确做法是用 makestep + offline/online
没有 chrony burst 这个命令。所谓“burst 同步”实际是让 chronyd 在短时间内密集轮询服务器，这需要先标记源为离线再强制在线，配合 makestep 生效：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
- 临时停掉所有 NTP 源：
chronyc offline - 强制立即跳变（即使偏移小于 makestep 阈值）：
chronyc makestep - 重新启用源并快速拉取数据：
chronyc online && chronyc burst 4/8（注意：burst是 chronyc 的子命令，格式为burst N/M，表示向每个源发 M 次包、成功 N 次即停止） - 观察效果：
chronyc sources -v看延迟和偏移变化；chronyc tracking确认Offset是否归零附近
容易忽略的硬性限制和副作用
强制跳变系统时间不是万能操作，尤其在生产环境要警惕以下几点：
- chronyd 的
makestep对adjtimex()系统调用有依赖，若内核禁用了CLOCK_REALTIME修改（如某些容器或 hardened kernel），跳变会静默失败 - 应用层依赖单调时钟（如 Go 的
time.Now()、Java 的System.nanoTime()）不受影响，但依赖CLOCK_REALTIME的日志、数据库事务时间戳、TLS 证书校验可能出错 - 虚拟机中若启用了
rtcsync，主机时间突变会导致 guest RTC 被覆盖，进一步放大混乱 -
chronyc burst只作用于当前在线的 NTP 源，若sources列表为空（比如网络不通或 DNS 失败），该命令无任何效果
真正棘手的从来不是怎么跳时间，而是跳完之后谁还在用旧时间戳——这点在分布式日志聚合或金融交易场景里，往往比同步本身更难排查。
