返回

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

Linux

揪出幕后黑手: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。可问题依旧,该重启还是重启。journalctldmesg 也没给啥有用的信息。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 错误并伴随硬重置,这仍然是个强烈的怀疑点,但我们不能排除其他可能。

一、 为啥会随机重启?

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

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

    仔细翻看,注意任何 segfaulthardware errorkernel oopspanic 或者服务异常退出的信息。

  • 内核环形缓冲区 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,确认 nowatchdognmi_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 是否有异常日志。

三、 下一步怎么走?

排查随机重启问题通常是个排除法过程,需要耐心和细致。

  1. 先从简单的开始: 仔细检查所有日志,运行标准的硬件健康检查(IPMI sensor, SMART)。
  2. 尝试非 RT 内核: 这是区分是否与实时内核特性相关的关键一步。
  3. 内存测试: Memtest86+ 是必做项。
  4. 压力测试: 在监控温度和系统日志的同时进行,尝试复现问题。
  5. 如果上述都无效,深入驱动和 kdump: 这可能需要更多时间和专业知识。

记录下你每次尝试的改动和观察到的结果,这样才能系统地逼近问题根源。祝你好运!