chronyc tracking Leap status "Insert second" 的夏令时跳跃处理

2026-01-31 00:00:00 作者：舞姬之光

“Insert second”不是夏令时问题，而是chronyd准备插入UTC闰秒；需内核支持adjtimex且配置正确才能生效，否则仅记录日志或卡住状态。

chronyc tracking 显示 "Leap status: Insert second" 是夏令时问题吗？

不是。这个状态和夏令时（DST）完全无关，它表示 chronyd 正在准备插入一个闰秒（leap second），即在 UTC 时间 23:59:60 多加一秒。夏令时切换是本地时区的偏移变更（如 CET → CEST），由 tzdata 和系统时区配置控制，chronyd 不参与、也不感知 DST 跳跃。

"Insert second" 状态下 chronyd 是否会自动处理闰秒？

取决于配置和系统内核支持：

chronyd 默认启用闰秒插入（leapsectz 指令未禁用），且系统时区文件（/usr/share/zoneinfo/right/ 下的 tzdata）包含闰秒信息时，它会在 UTC 时间到达前约 24 小时进入 Insert second 状态，并在指定时刻通过 CLOCK_ADJTIME 系统调用向内核注入闰秒
但前提是内核必须启用 CONFIG_RTC_DRV_CMOS 或支持 adjtimex(2) 的高精度时钟源；否则 chronyd 只能记录日志，无法实际插入，状态可能卡住或降级为 Not synchronised
若使用 makestep 或 rtcsync，它们与闰秒处理正交——makestep 修正大偏差，rtcsync 同步 RTC，都不影响闰秒逻辑

如何验证当前系统是否真正执行了闰秒插入？

不能只看 chronyc tracking 输出，需交叉检查：

查看 chronyd 日志：journalctl -u chronyd | grep -i "leap.*insert\|leap second"，确认是否有 Inserting leap second 或 Leap second inserted
检查内核时间状态：adjtimex -p | grep "status\|leap"，输出中 status 值为 0x2001（含 STA_INS 标志）表示已置入插入标志；leap 字段为 1 表示等待插入，0 表示已完成或
取消
对比 UTC 时间源：用 chronyc sources -v 确认上游服务器（如 pool.ntp.org）本身是否广播闰秒预告（leap indicator 字段为 01）；若上游没发，chronyd 不会主动插入

生产环境遇到 "Insert second" 卡住或跳变异常怎么办？

常见于容器、虚拟化或老旧内核场景：

容器中默认无权限调用 adjtimex，需添加 cap_sys_time 能力，或改用 chronyd -q + systemd-timedated 间接同步（牺牲闰秒精度）
KVM/QEMU 虚拟机若启用了 host-time 或 rtc_clock=host，宿主机时间跳变会直接透传给客户机，此时 chronyd 的闰秒插入可能冲突甚至失败——应禁用宿主机 RTC 同步，仅依赖 NTP
Linux 5.4+ 内核引入 CONFIG_TIME_NS，容器时间命名空间可能隔离闰秒状态，导致 adjtimex 返回 EPERM；需升级 chrony ≥ 4.0 并启用 leapsecmode 1（由用户态模拟闰秒）