一、问题背景：无硬件告警却频繁重启的诡异现象

线上部署的几台银河麒麟服务器最近出现了很特殊的状况：每天凌晨会自动重启，监控系统完全没触发任何硬件告警，电源指示灯是正常的绿色，风扇转速也在合理范围，硬件层面查不出任何问题，但重启后业务会短暂中断，影响客户使用。刚开始以为是定时任务出了问题，把凌晨的定时任务全停了，结果还是会自动重启，这时候就需要从系统层面找深层次的原因了。

二、三个核心工具：pstore、kdump、内核日志是什么？

2.1 pstore：掉电也能存的“故障临时病历本”

pstore是内核提供的一个轻量功能，它会把关键故障日志存在非易失性存储介质里，比如BIOS闪存或小的磁盘分区，就算服务器突然断电重启，这些日志也不会丢失。它就像你随身带的应急记事本，哪怕设备没电关机，之前记的关键信息还能找回。查看pstore内容很简单，直接读对应的虚拟文件即可：

# 查看pstore中保存的控制台日志，console-ramoops是pstore的日志分区
cat /sys/fs/pstore/console-ramoops*

这个命令运行后会输出服务器崩溃或重启时的控制台信息，比如有没有内存错误、电源管理相关报错，这些信息是硬件日志里看不到的，是系统层面的第一手线索。

2.2 kdump：内核崩溃时的“事故记录仪”

kdump是专门捕获内核崩溃现场的工具，当内核出现严重错误导致崩溃时，kdump会把崩溃时的完整内存备份下来，生成叫vmcore的文件，就像车祸后的现场照片，能让我们清晰看到当时的触发原因。确认kdump是否启用、有没有生成过崩溃文件，用这几个命令：

# 检查kdump服务是否已经启用
systemctl is-enabled kdump
# 查看kdump转储文件的默认存储目录，一般在/var/crash/下
ls /var/crash/

如果执行ls /var/crash/后看到类似“127.0.0.1-2024-05-20-03:15:00”的目录，说明之前内核崩溃过，保存了现场数据，接下来就能用crash工具分析这个vmcore文件了。

2.3 内核日志：服务器的“日常运行日记”

内核日志是内核运行时记录的所有信息，就像服务器的日记，不管是硬件小问题还是系统异常，都会记下来。银河麒麟用systemd管理日志，用journalctl命令查看更方便筛选时间范围：

# 查看最近7天的内核日志，按时间排序，方便匹配重启时间段
journalctl -k --since "7 days ago" | sort

通过这个命令能找到对应重启时间点前后的日志内容，看看有没有异常报错信息。

三、排查实战：一步步揪出故障根源

3.1 先查pstore，找重启前的关键线索

pstore的日志不会因服务器重启或掉电丢失，是最早能拿到的线索。运行之前的cat命令，输出里如果有类似“ACPI: PM: resume failed”（电源管理恢复失败）或者“Memory error: Corrected error”（内存错误）的关键词，就能大概定位故障类型。比如某次排查时，pstore输出里有： “[ 2.123456] ACPI: PSCI: failed to suspend/resume: -110” 这说明电源管理在挂起恢复时出了问题，大概率是服务器重启的原因。

3.2 再查kdump，确认内核崩溃的现场

如果pstore没找到明确线索，就看kdump的转储文件。先进入对应的转储目录，安装crash工具分析vmcore：

# 切换到最近的kdump转储目录，替换成实际的时间目录
cd /var/crash/127.0.0.1-2024-05-20-03:15:00/
# 银河麒麟环境下安装crash工具，用于分析vmcore文件
apt install crash -y
# 用crash工具分析崩溃现场，指定当前内核的vmlinux文件和转储文件
crash /usr/lib/debug/boot/vmlinux-$(uname -r) ./vmcore

进入crash交互界面后，输入log命令，就能查看崩溃时的内核日志，找到oops（内核严重错误）的栈信息或电源管理相关的调用链，直接定位故障函数或驱动程序。

3.3 最后查内核日志，匹配重启的时间线

如果pstore和kdump都找不到问题，就看内核日志，因为它有完整的运行记录。筛选对应重启时间段的日志：

# 查看昨天凌晨3点到3点10分的内核日志，匹配重启时间段
journalctl -k --since "2024-05-20 03:00:00" --until "2024-05-20 03:10:00"

运行后如果发现“CPU: 0 PID: 1234 Comm: systemd-suspend Tainted: G W O”的内容，说明系统尝试挂起时出了问题，systemd-suspend是处理电源挂起的服务，就能确定是电源管理故障；如果看到“memory error: page 0x12345678 has error”，则是内存的隐性故障。

四、故障关联：电源管理还是内存问题？

4.1 电源管理故障的典型特征

如果排查后日志里有ACPI（高级配置和电源接口）相关错误，比如PM resume失败、PSCI调用失败，或者电源管理驱动的oops，那就是电源管理层面的问题。这种情况一般是内核电源驱动的bug，或者BIOS里的电源节能设置太激进，导致内核唤醒时出错。

4.2 内存故障的典型特征

如果日志里有memory error相关关键词，比如corrected error（内存软错误，可被硬件校正的错误）、uncorrected error（内存硬错误，不可校正的错误），或者crash分析里有页错误涉及内存地址，那就是内存的隐性故障。这种时候硬件没触发告警，是因为错误还没达到硬件告警阈值，或者是可校正的软错误，但已经足以导致内核崩溃重启。

五、应用场景、技术优缺点与注意事项

5.1 应用场景

这些工具最适合的场景是：服务器出现异常重启，但硬件层面无任何告警，监控系统也没捕捉到错误，业务短暂中断但又找不到明确原因的情况。比如线上业务凌晨随机重启的问题，用这三个工具能快速定位是内核层面的电源或内存故障，而非外部定时任务或硬件问题。

5.2 技术优缺点

pstore的优点是：日志存在非易失性介质，不会因重启或掉电丢失，部署简单无需额外配置；缺点是：存储空间有限，只能保存最近的故障日志，可能被后续日志覆盖，且只能记录关键控制台信息，无法保存完整内存现场。 kdump的优点是：能捕获完整的内核崩溃现场，不管是电源还是内存问题，都能通过vmcore分析到最底层原因；缺点是：需要在GRUB里预留内存给kdump，占用系统内存资源，配置相对复杂，需开启对应内核选项。 内核日志的优点是：实时记录所有系统运行信息，查询方便，能匹配时间线找对应问题；缺点是：服务器重启后，未配置持久化的日志会被覆盖，只能找到重启前的部分信息，且日志量太大，筛选耗时。

5.3 注意事项

排查时要注意几个关键点：第一，pstore需要内核配置开启CONFIG_PSTORE选项，否则/var/fs/pstore目录可能不存在，需手动开启；第二，kdump需在/etc/default/grub里配置crashkernel参数（比如crashkernel=128M），更新GRUB并重启后才能生效；第三，内核日志要配置持久化存储，把/var/log/journal挂载到独立磁盘分区，避免重启丢失；第四，分析vmcore时，必须用和崩溃时对应内核的vmlinux文件，否则分析结果会出错。

六、实战总结

我们近期排查过两台类似故障的服务器：一台是pstore里有“ACPI: PSCI: resume failed”日志，kdump分析后发现是power_supply_resume函数的oops，属于电源管理驱动bug，升级驱动后问题解决；另一台是pstore里有“Memory error: Corrected error”，内核日志匹配到内存某页错误，更换对应内存后，凌晨重启的问题彻底消失。所以这三个工具结合使用，能轻松定位这类无硬件告警的诡异重启问题。