闰秒触发 rcu_sched stall 导致 CPU 卡死，表现为 SSH 响应慢、top 无响应、某 CPU softirq 占比异常高；需在闰秒前 2 小时停 ntpd，事后 1 小时重启，或改用 sntp 定期同步，升级至 3.10+ 内核可根治。
闰秒触发 rcu_sched stall 导致 CPU 卡死
Linux 在闰秒发生时，若内核版本存在已知缺陷（如 2.6.18-164.el5 及更早），NTP 通知内核插入闰秒会引发 rcu_sched 宽限期无法完成，最终触发 rcu_sched self-detected stall on CPU。此时系统表现为：SSH 响应极慢或断连、top 无响应、mpstat -P ALL 1 显示某 CPU 持续 100% 且 softirq 占比异常高，dmesg 中反复刷出 stall 日志。
停掉 ntpd 是最直接的临时缓解手段
闰秒通知由 NTP 客户端（ntpd）提前约 24 小时接收并注册到内核，真正卡死往往发生在闰秒前几小时就已开始。因此，不能等“闰秒时刻”再操作。
- 在 IERS
Bulletin C公布闰秒日期后（通常提前 6 个月），立即规划维护窗口 - 闰秒发生前 2 小时执行：
sudo systemctl stop ntpd或sudo service ntpd stop（RHEL/CentOS） - 确认已停止：
pgrep ntpd应无输出；ntpq -p报错 “no response” - 闰秒过后至少 1 小时，再执行
sudo systemctl start ntpd，让时间平滑追赶
注意：systemctl restart ntpd 不可靠——重启过程仍可能触发闰秒处理逻辑。
用 sntp 替代 ntpd 可绕过内核闰秒事件注册
ntpd 是持续运行的守护进程，会主动向内核注册闰秒回调；而 sntp（来自 ntp 包）是单次同步工具，不驻留、不注册、不干预内核时间跳变逻辑，天然规避该问题。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 卸载
ntpd：sudo yum remove ntp（RHEL/CentOS）或sudo apt purge ntp（Debian/Ubuntu） - 安装
ntpdate或sntp（部分发行版需启用 epel） - 改用 cron 定期同步（例如每 15 分钟）：
*/15 * * * * /usr/bin/sntp -sS pool.ntp.org >/dev/null 2>&1 - 关键点：
sntp -sS强制使用settimeofday()系统调用，不触发内核闰秒状态机
该方案在腾讯 OS Server、部分金融交易系统中已长期验证有效，但需接受 ±50ms 级别的时钟误差（对绝大多数业务可接受）。
升级内核或打补丁才是根治方式
Linux 内核在 2.6.39 后引入 clock_was_set() 重写，3.10+ 版本基本修复了闰秒导致的 rcu stall；RHEL 7.2+（内核 3.10.0-327）及 CentOS 7.3+ 已包含对应修复。
- 检查当前内核：
uname -r，若低于3.10.0，强烈建议升级 - 如无法升级，可考虑打社区补丁（如 Red Hat 提供的
kernel-rt补丁集），但需严格测试 - 注意：某些定制内核（如某些 RT-Linux 发行版）即使版本较新，也可能因裁剪掉
CONFIG_RCU_STALL_COMMON或修改时间子系统而表现异常
真正麻烦的不是闰秒本身，而是旧内核里那个被唤醒后永远无法退出的 rcu 回调——它不报错、不崩溃，只把某个 CPU 核心钉死在软中断里，连 perf 都难抓到栈帧。这种静默卡死，最容易被误判为硬件故障。
