“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（由用户态模拟闰秒）
闰秒不是“每到夏天就来一次”的常规操作，十年最多两次，但一旦出错会影响金融、日志时序、分布式锁等对单调时间敏感的系统——别把它当成 DST 那样忽略，也别在没验证内核和容器权限的情况下假设它“自动生效”。
