Debian+SMC服务器随机重启：根源排查与解决指南

2025-04-02 21:03:18

揪出幕后黑手：Debian 系统（SMC 硬件）随机重启问题排查指南

服务器不定时抽风重启，日志里还找不到明确线索？这事儿挺头疼的，尤其是在 SMC (Supermicro) 这种常见的服务器硬件上跑 Debian 系统的时候。别急，咱们一步步来分析，把导致这随机重启的“真凶”找出来。

根据，系统环境是 Debian 12 (bookworm) 跑在 SMC SYS-111E-FWTR 硬件上，用了个实时内核 6.1.0-28-rt-amd64。你已经尝试了在 BIOS 和 Linux 内核参数里禁用 watchdog (nmi_watchdog=0 nowatchdog)，甚至通过 ipmitool 把 BMC 的 watchdog 触发动作改成了 No action。可问题依旧，该重启还是重启。journalctl 和 dmesg 也没给啥有用的信息。last reboot 显示重启确实发生了，但 why 还是个谜。

# ipmitool mc watchdog get
Watchdog Timer Use:     SMS/OS (0x44)
Watchdog Timer Is:      Started/Running  # 看门狗还在运行
Watchdog Timer Logging: On
Watchdog Timer Action:  No action (0x00) # 动作确实改成了“无操作”
Pre-timeout interrupt:  None
Pre-timeout interval:   0 seconds
Timer Expiration Flags: (0x10)
                        * SMS/OS
Initial Countdown:      300.0 sec
Present Countdown:      249.5 sec # 倒计时还在走

# bmc-watchdog --get # 另一个工具确认，结果一致
Timer Use:                   SMS/OS
Timer:                       Running
Logging:                     Enabled
Timeout Action:              None
# ... 省略部分输出 ...
Initial Countdown:           300 seconds
Current Countdown:           283 seconds

# last reboot 显示了近期的重启记录
reboot   system boot  6.1.0-28-rt-amd6 Wed Feb 26 08:46   still running
reboot   system boot  6.1.0-28-rt-amd6 Wed Feb 26 07:18 - 08:43 (01:25)
reboot   system boot  6.1.0-28-rt-amd6 Tue Feb 25 20:42 - 08:43 (12:01)

# uptime 和 date 确认当前运行时间和日期
~# uptime
10:15:03 up 1:28,  7 users,  load average: 7.28, 7.76, 7.75
~# date
Wed Feb 26 10:15:05 AM EAT 2025

尽管 IPMI watchdog action 设置为 None，但它仍在运行并由 SMS/OS 使用。这意味着操作系统（或某个系统服务）应该定期 "喂狗"（重置计时器）。如果系统完全卡死，无法喂狗，计时器最终会归零。虽然设置为 No action，理论上 BMC 不应执行硬重置，但有时 BMC 的行为可能不完全符合预期，或者问题的根源并非 watchdog 超时本身。IDRAC（虽然 SMC 通常用 IPMI/BMC，但概念类似，指带外管理）日志提到 watchdog 错误并伴随硬重置，这仍然是个强烈的怀疑点，但我们不能排除其他可能。

一、为啥会随机重启？

随机重启的原因五花八门，大致可以归为几类：

硬件耍赖:
- 内存条不稳定或损坏。
- CPU 过热或有问题。
- 主板元件故障。
- 电源供应不稳定 (PSU 问题)。
- 硬盘/SSD 故障导致系统关键进程崩溃。
- 其他扩展卡（网卡、RAID 卡等）冲突或故障。
软件层面:
- 内核恐慌 (Kernel Panic): 内核遇到无法恢复的错误，可能直接重启。实时内核 (RT Kernel) 对时序要求更严格，某些驱动或硬件交互可能更容易触发问题。
- 驱动程序 Bug: 特别是像 ice (Intel E810 系列网卡), iavf (虚拟功能), mlx5_core (Mellanox/NVIDIA 网卡) 这类高性能网络驱动，有时存在可能导致系统不稳定的 Bug。
- 系统服务或应用软件: 某个关键服务崩溃，或者某个应用软件触发了内核深层的问题。
- 配置错误: 错误的系统配置也可能间接触发重启。
Watchdog 问题:
- 系统 Watchdog 服务: Linux 内核有自己的 watchdog 机制 (/dev/watchdog)，通常由 watchdog 守护进程或 systemd 喂狗。如果这个进程挂了，内核 watchdog 超时也可能触发重启（取决于配置和硬件）。
- BMC Watchdog (IPMI): 底层管理控制器 (BMC) 的独立 watchdog。通常由操作系统通过 IPMI 工具（如 ipmitool 或特定守护进程）喂狗。如果 OS 失去响应，BMC watchdog 超时，根据配置执行动作（如重启）。你已经尝试禁用其重启操作，但仍需确认其行为是否符合预期。
环境因素:
- 过热: 机房温度过高或服务器散热不良。
- 供电问题: 电力波动、UPS 故障、PDU (电源分配单元) 问题。

二、排查步骤走起！

咱们得像侦探一样，一步步缩小范围，找出真凶。

1. 日志再挖掘：不止 `journalctl`

虽然你说 journalctl 没啥帮助，但有时信息藏得比较深。咱们换几个姿势再看看：

查看上一次启动的日志: journalctl -b -1 -p err
这条命令会显示上一次启动（也就是重启前的最后一次运行）的所有错误级别（err）及以上的日志。看看崩溃前有没有什么异常报错。-p warning 或 -p notice 也可以试试，有时问题线索在更低级别的日志里。
根据时间范围过滤: 找到 last reboot 显示的重启时间点，比如 Wed Feb 26 07:18。然后查看这个时间点前几分钟的日志：
```
# 假设重启发生在 07:18 左右，我们看 07:10 到 07:20 的所有日志
journalctl --since "2025-02-26 07:10:00" --until "2025-02-26 07:20:00"
```
仔细翻看，注意任何 segfault、hardware error、kernel oops、panic 或者服务异常退出的信息。
内核环形缓冲区 dmesg: 重启后立即执行 dmesg -T。它会显示内核启动信息和运行期间的硬件/驱动消息。留意是否有关于 CPU、内存、PCIe 设备（特别是网卡）的错误。-T 参数会显示人类可读的时间戳。
```
dmesg -T | less
# 搜索，如 error, fail, warn, panic, oops
```
传统日志文件: 检查 /var/log/syslog, /var/log/kern.log。虽然 systemd-journald 是主流，但有些信息可能还是会往传统日志里写。同样，关注重启时间点附近的记录。
确保日志持久化: 确认 journald 配置为持久化存储日志，否则重启后 /run/log/journal 下的日志就没了。检查 /etc/systemd/journald.conf 中的 Storage 设置，确保不是 volatile。如果是，改成 persistent (mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal 可能需要手动创建目录并设置权限)，然后 systemctl restart systemd-journald。

2. Watchdog 再确认：真的关了吗？

你做了很多 watchdog 相关的操作，但咱们再仔细捋一捋：

内核 Watchdog:
- 确认内核参数生效: 重启后检查 cat /proc/cmdline，确认 nowatchdog 和 nmi_watchdog=0 确实在里面。
- 检查 watchdog 模块: lsmod | grep wdt 看看是否加载了硬件相关的 watchdog 模块（比如 iTCO_wdt 等）。如果 nowatchdog 参数生效，理论上不应加载。如果加载了，可能需要通过 /etc/modprobe.d/ 下的配置文件 blacklist 掉它。例如，创建一个文件 /etc/modprobe.d/blacklist-watchdog.conf，内容为：
```
blacklist iTCO_wdt
blacklist iTCO_vendor_support
# 如果有其他可疑的 wdt 模块也加进去
```
  然后更新 initramfs (update-initramfs -u) 并重启。
- 检查系统 Watchdog 服务: 确认 watchdog 守护进程（如果安装了）或 systemd 的 watchdog 功能没有被意外激活并配置错误。systemctl status watchdog 或检查 systemd 单元文件（/etc/systemd/system.conf 或 /etc/systemd/system.conf.d/*.conf）中的 RuntimeWatchdogSec= 和 ShutdownWatchdogSec= 设置。
BMC Watchdog (IPMI):
- ipmitool mc watchdog get 确认: 你的输出显示 Timer Use: SMS/OS, Timer: Running, Timeout Action: None。这意味着 BMC watchdog 在跑，依赖操作系统喂狗，超时后“不执行动作”。这 理论上 应该阻止了 BMC 主动重启。
- IDRAC/BMC 日志: IDRAC (Integrated Dell Remote Access Controller) 是戴尔的叫法，SMC 用的是 IPMI/BMC。你需要登录到服务器的 BMC Web 界面，或者使用 ipmitool sel elist (查看 System Event Log) 来获取 BMC 层面的日志。重点关注重启时间点附近的事件。即使 Action 是 None，超时事件本身可能还是会被记录下来，这能确认是否与 OS 无响应有关。
```
ipmitool sel elist
# 查看 BMC 系统事件日志，信息量很大，需要耐心查找
ipmitool sel clear # 可以清除日志方便下次观察，但请先保存好当前日志！
```
- 尝试临时启用日志记录超时事件： 你可以尝试 ipmitool mc watchdog reset 来看看能否临时关闭它（有些 BMC 支持），或者把超时时间设得很长（比如 15 分钟 ipmitool mc watchdog set 900），然后密切观察 BMC 日志，看看在下次随机重启时，BMC 是否记录了明确的 watchdog 超时事件。如果记录了，说明 OS 确实在超时前完全挂死了；如果没有记录，说明重启原因可能不是 OS 无响应导致的 BMC watchdog 超时。

3. 硬件健康状况检查：该“体检”了

随机重启，硬件嫌疑很大。

IPMI 传感器数据: 这是排查硬件问题最有力的工具之一。
```
ipmitool sensor list
# 关注 温度(Temperature), 电压(Voltage), 风扇转速(Fan)
# 查找状态不是 'ok' 或 'nr'(Not Reading) 的传感器
# 对比厂商文档确认正常范围
ipmitool sensor list | grep -iE 'temp|volt|fan|power|err'
```
检查 CPU 温度、内存温度、主板各处温度是否过高。检查电压读数是否稳定，在正常范围内 (+12V, +5V, +3.3V, VCORE 等)。风扇转速是否正常？有无告警？
内存测试 (RAM Test): 内存不稳定是随机重启的常见元凶。
- 推荐方式: 使用 Memtest86+ 。制作一个 Memtest86+ 的 USB 启动盘，从 U 盘启动服务器，让它运行完整的内存测试，最好跑上几个循环 (pass)，或者直接跑过夜。任何红色报错都意味着内存有问题。
- 系统内测试: memtester 工具可以在 Linux 运行时测试一部分内存，但不如离线测试彻底。
```
sudo apt install memtester
# 测试 4G 内存，跑 3 遍
sudo memtester 4G 3
```
  这个测试会给系统带来压力，如果内存在高负载下不稳定，可能在测试中就触发重启或报错。

CPU 压力测试: 排除 CPU 过热或计算错误。

sudo apt install stress-ng # 功能更全的压力测试工具
# 对所有 CPU 核心施加压力，持续 10 分钟
stress-ng --cpu 0 --timeout 600s --metrics-brief
# 同时监控温度 (需要另开一个终端)
watch -n 1 'ipmitool sensor list | grep -i temp'
# 或者使用 `sensors` 命令 (如果 lm-sensors 配置好了)
watch -n 1 sensors

观察测试期间系统是否稳定，温度是否飙升到危险水平 (通常超过 85-95°C 需要警惕，具体看 CPU 型号)。

硬盘/SSD 检查: smartctl 工具可以检查硬盘的 S.M.A.R.T. 状态。

sudo apt install smartmontools
# 列出磁盘设备，找到你的系统盘，比如 /dev/sda
lsblk
# 对系统盘运行全面健康检查
sudo smartctl -a /dev/sda
# 关注 'SMART overall-health self-assessment test result' 是否为 PASSED
# 查看 Reallocated_Sector_Ct, Current_Pending_Sector 等数值是否异常（非 0 需警惕）

物理检查与连接:
- 断电后 打开机箱，检查所有连接线（电源线、数据线）是否牢固。
- 重新插拔 内存条、CPU (如果敢的话，注意散热硅脂)、PCIe 卡（特别是那几个网卡）。有时仅仅是接触不良。
- 清理灰尘！ 灰尘是散热杀手。用压缩空气罐或吹风机（冷风档）彻底清理散热片、风扇和电源内部。
- 检查电容: 看看主板、电源、扩展卡上有没有鼓包或漏液的电容。

4. 内核、驱动与实时特性：RT 内核的“锅”？

实时内核 (-rt) 对时序和中断处理非常敏感，有时与某些驱动或硬件行为不太“合拍”。

尝试标准内核: Debian 官方源里通常有标准的非 RT 内核。
```
sudo apt update
sudo apt search linux-image-amd64 # 找最新的非 -rt 内核版本
sudo apt install linux-image-[version]-amd64 # 安装你找到的版本
sudo update-grub
```
重启后，在 GRUB 菜单选择新安装的标准内核启动。运行一段时间，看看随机重启问题是否消失。如果用标准内核就稳定了，那问题很可能出在 RT 内核与某个驱动（很可能是网卡驱动 ice, iavf, mlx5_core 中的一个）或硬件的交互上。
驱动版本问题: 你用的驱动版本 ice (v1.15.5), iavf(v4.12.6), mlx5_core(24.10-1.1.4)。检查一下这些版本对于你的硬件、Debian 12 以及 Kernel 6.1-rt 是否是推荐或兼容的版本。有时最新版驱动反而不稳定，或者需要特定固件 (firmware) 配合。
- 去 Intel (ice, iavf) 和 NVIDIA/Mellanox (mlx5_core) 官网查找驱动下载和发布说明，看是否有关于稳定性的说明或已知问题。
- 考虑尝试降级或升级 这些网卡驱动到官方推荐的稳定版本。这通常需要从源码编译安装，或者查找是否有打包好的 .deb 文件。
内核崩溃转储 (Kdump): 如果怀疑是 Kernel Panic 但日志里看不到，配置 kdump 是最终大招。kdump 能在内核崩溃时捕获内存快照 (vmcore)，事后可以分析崩溃原因。
```
sudo apt install kdump-tools
# 配置 /etc/default/kdump-tools，主要是设置好转储路径和核心文件选项
# 可能需要调整内核参数预留内存给 kdump 内核 (crashkernel=...)
# 具体配置参考 Debian Wiki 或 kdump 文档
sudo systemctl enable kdump-tools
sudo systemctl start kdump-tools
```
配置完成后，如果再发生内核恐慌导致的重启，它会先启动一个迷你内核将内存 dump 到指定位置。然后你需要用 crash 工具来分析 vmcore 文件。这个过程比较复杂，但能提供最直接的崩溃证据。
Machine Check Exceptions (MCE): 硬件（尤其是 CPU）检测到内部错误时会触发 MCE。有时 MCE 不会立刻导致崩溃，但会被记录下来。
```
sudo apt install mcelog
sudo systemctl enable mcelog
sudo systemctl start mcelog
# 查看 MCE 日志
sudo mcelog --syslog # 或者直接看 /var/log/mcelog
```
如果 mcelog 记录了错误，需要根据错误信息判断是哪个硬件出了问题。

5. 电源和散热再次审视

虽然 IPMI 传感器看过了，但有些问题不一定能直接读出来。

负载相关性: 重启是否总发生在系统负载较高的时候？如果是，强烈怀疑散热或电源供电能力不足。跑压力测试 (stress-ng) 时如果更容易复现，就印证了这一点。
电源单元 (PSU): SMC 服务器通常有冗余电源。检查两个电源模块是否都工作正常（指示灯状态），BMC 日志里是否有电源相关的事件。有可能是一个电源模块有问题，导致在特定负载下供电不稳。可以尝试只用一个电源模块运行（如果另一个确定是好的），看看问题是否复现或改变。
数据中心环境: 确认机柜的散热和供电没有问题。询问同事最近是否有数据中心的维护或电力波动。检查连接服务器的 PDU 是否有异常日志。