OpenEuler 服务器宕机定位流程（含错误位置排查）
一、定位前准备：现象确认与基础信息收集
在开展深入分析前，需先明确宕机具体表现，收集基础环境信息，为后续定位提供依据：
- 网络连通性测试
- 操作：执行 ping 服务器IP 命令，观察是否能正常响应。
- 判定：能 Ping 通但无法 SSH 连接 → 大概率为系统 Hang（死机）；Ping 不通 → 可能是内核崩溃或网络栈死锁。
- 带外管理卡检查
- 操作：登录 BMC/IPMI 远程管理界面，查看硬件状态（如 CPU 温度、电源、风扇、内存等），是否存在硬件报警提示。
- 本地终端状态确认
- 操作：若服务器连接显示器，观察宕机时屏幕是否显示报错信息（如 Kernel panic（内核崩溃）、Oops（内核警告）等）。
- 基础环境信息记录
- 记录服务器硬件配置（CPU 型号、内存容量、磁盘类型 / 数量）、OpenEuler 系统版本（执行 cat /etc/openEuler-release 获取）、近期是否进行过系统更新 / 软件安装 / 配置修改。
二、通用排查：系统日志分析（核心步骤）
无论宕机表现为 “重启” 或 “死机”，均需先通过系统日志排查宕机前异常记录，定位潜在错误位置。
2.1 内核日志与系统消息日志排查
2.1.1 查看内核缓冲区信息（dmesg） - 命令：
查看最近100条内核日志（重点关注宕机前记录）
dmesg | tail -n 100
筛选关键错误信息
dmesg | grep -iE “error|warn|fail|panic|oops|out of memory|i/o error”
- 核心关注关键词及对应错误位置：
- OOM Killer → 内存不足，系统强制终止进程导致宕机；
- I/O error → 磁盘读写故障（如坏道、线缆松动、控制器异常）；
- BUG/WARNING → 内核代码断言触发，可能是内核漏洞或驱动冲突；
- task blocked for more than 120 seconds → 进程死锁或资源耗尽（导致系统 Hang）；
- Kernel panic/Oops → 内核崩溃，需进一步分析调用链。
2.1.2 查看系统消息日志（messages/journalctl）
- 命令：
方法1：查看messages日志（按时间倒序）
cat /var/log/messages | grep -iE “error|warn|fail|panic|oops”
方法2：通过journalctl查看内核日志（更全面，支持按时间筛选）
journalctl -k # 查看所有内核日志
journalctl -k -e # 查看内核日志尾部（最近记录）
journalctl -k --since “1小时前” # 查看1小时内的内核日志
2.2 系统状态与历史记录排查
2.2.1 查看系统重启 / 登录记录
- 命令：
查看系统重启、关机、登录历史（last -x 包含系统事件）
last -x | head -n 20
筛选重启记录
last -x | grep “reboot”
- 用途：确认宕机是否导致系统重启，以及重启时间点，对应日志中的异常记录。
2.2.2 查看宕机前后系统负载（sar 工具） - 前提：需安装 sysstat 工具（默认可能未安装）
安装命令：yum install -y sysstat - 命令：
查看指定日期的系统负载日志（XX为日期，如sa22代表22日）
sar -u -r -q -f /var/log/sa/saXX
- 参数说明：
- -u：CPU 使用率； -r：内存使用率； -q：系统负载（运行队列长度）。
- 用途：排查是否因 CPU / 内存过载导致宕机。
三、场景 1：系统重启（内核崩溃 / Kernel Panic）定位
若服务器宕机后自动重启，说明发生内核崩溃，核心依赖 kdump 生成的崩溃转储文件（vmcore）定位错误位置。
3.1 检查 kdump 崩溃转储文件
3.1.1 确认是否生成 vmcore 文件 - 命令：
查看kdump默认存储目录（配置文件为/etc/kdump.conf）
ls -lt /var/crash/
- 判定：若存在类似 127.0.0.1-202X-XX-XX-XX:XX:XX 的目录，说明成功捕获崩溃转储（含 vmcore 文件）。
3.1.2 分析 vmcore 文件（定位崩溃根源） - 步骤 1：安装 crash 分析工具
命令：yum install -y crash - 步骤 2：查找 vmlinux 文件（内核调试符号文件）
命令：find /usr/lib/debug/lib/modules/ -name vmlinux
（通常路径：/usr/lib/debug/lib/modules/$(uname -r)/vmlinux） - 步骤 3：启动 crash 交互式分析
命令：
进入crash目录（替换为实际目录名）
cd /var/crash/127.0.0.1-202X-XX-XX-XX:XX:XX/
执行分析（替换vmlinux实际路径）
crash /usr/lib/debug/lib/modules/XXX/vmlinux vmcore
- 核心分析命令（在 crash 交互界面输入）：
- bt：打印崩溃时的内核堆栈（Call Trace），直接查看导致崩溃的函数调用链，定位错误模块（如驱动、内核组件）；
- ps：查看崩溃时运行的进程，确认是否由特定进程触发；
- log：查看崩溃时的内核日志；
- mod：查看加载的内核模块，排查模块冲突。
3.2 若未生成 vmcore 文件：检查 kdump 配置
3.2.1 查看 kdump 服务状态
- 命令：
systemctl status kdump
若未启动，执行启动命令
systemctl start kdump
设置开机自启
systemctl enable kdump
3.2.2 验证 kdump 配置文件
- 配置文件路径：/etc/kdump.conf
- 关键配置项（确保正确设置）：
- path /var/crash：转储文件存储路径；
- core_collector makedumpfile -c -l -message-level 1 -d 31：转储文件压缩配置；
- 重启 kdump 服务：systemctl restart kdump
四、场景 2：系统死机（无响应 / System Hang）定位
若服务器未重启，但出现键盘无反应、SSH 断连、进程无法执行等卡死状态，需通过应急手段收集信息或强制生成日志。
4.1 应急操作：Magic SysRq Key（魔法键）
Magic SysRq 是内核提供的应急调试功能，可在系统 Hang 时强制输出关键信息或恢复系统。
4.1.1 操作方式 - 物理服务器：直接按键盘组合键 Alt + SysRq (PrintScreen) + 对应字母；
- 远程管理卡：通过 BMC/IPMI 的虚拟键盘执行上述组合键。
4.1.2 常用组合键（按优先级执行）
组合键
功能说明
Alt + SysRq + h
查看所有 Magic SysRq 支持的命令
Alt + SysRq + t
输出当前所有进程的 PID、CPU 占用、调用栈信息到系统日志（核心排查命令）
Alt + SysRq + m
输出内存使用详情（包括物理内存、交换分区、SLAB 缓存）到系统日志
Alt + SysRq + s
同步所有磁盘分区（防止数据丢失）
Alt + SysRq + e
向所有进程发送 SIGTERM 信号（安全终止进程，尝试恢复系统）
Alt + SysRq + i
向所有进程发送 SIGKILL 信号（强制终止进程，仅在 e 命令无效时使用）
Alt + SysRq + b
立即重启系统（最后手段，仅在无法恢复时使用）
4.1.3 查看 Magic SysRq 输出日志 - 命令：journalctl -k | grep “SysRq” 或 cat /var/log/messages | grep “SysRq”
4.2 长效配置：NMI Watchdog（非屏蔽中断看门狗）
若系统频繁 Hang 且无法通过 Magic SysRq 收集信息，可配置 NMI Watchdog，当系统卡死时强制触发内核崩溃并生成 vmcore，便于事后分析。
4.2.1 临时开启 NMI Watchdog（立即生效，重启失效） - 命令：echo 1 > /proc/sys/kernel/nmi_watchdog
4.2.2 永久开启 NMI Watchdog（重启后生效） - 编辑配置文件：vi /etc/sysctl.conf
- 添加配置项：kernel.nmi_watchdog = 1
- 生效配置：sysctl -p
4.2.3 触发 NMI 信号（系统 Hang 时） - 通过 BMC/IPMI 发送 NMI 信号：ipmitool chassis power diag
- 系统收到 NMI 信号后，会触发 Kernel Panic 并生成 vmcore，后续按 “场景 1” 的 vmcore 分析流程排查。
五、硬件层面排查（OpenEuler 特供工具）
若软件日志未发现异常，需排查硬件故障（如 CPU、内存、磁盘、电源等），OpenEuler 提供原生工具支持硬件状态检测。
5.1 查看硬件事件日志（SEL）
通过 ipmitool 工具读取 BMC 的系统事件日志（SEL），记录硬件错误（如温度过高、电压异常、风扇故障等）。 - 安装 ipmitool：yum install -y ipmitool
- 命令：ipmitool sel list
- 关注关键词：Temperature（温度）、Voltage（电压）、Fan（风扇）、Power（电源）、Critical（严重错误）。
5.2 磁盘健康状态检查（SMART）
通过 smartctl 工具检测磁盘是否存在坏道、寿命衰减等问题。 - 安装 smartmontools：yum install -y smartmontools
- 命令：smartctl -a /dev/sda（将sda替换为实际磁盘设备名，如sdb、nvme0n1）
- 关键判定：SMART overall-health self-assessment test result 需为 PASSED；若出现 Pre-failure 标识，说明磁盘存在故障风险。
5.3 CPU 硬件错误检查（MCE 日志）
CPU 硬件故障（如缓存错误、总线错误）会记录在 MCE（Machine Check Exception）日志中。 - 命令：
查看MCE日志文件
cat /var/log/mcelog
或通过journalctl查看
journalctl -t mcelog
- 关注关键词：CPU 0: Machine Check Exception、Uncorrected Error（不可纠正错误，需更换 CPU）、Corrected Error（可纠正错误，需监控是否频繁出现）。
5.4 内存故障排查 - 临时检测：执行 memtest86+ 工具（需通过 U 盘启动，适合离线检测）；
- 在线检测：安装 memstat 工具，执行 memstat -w 查看内存使用详情，排查内存泄漏或硬件故障。
六、快速定位流程图（简化版）
开始 → 服务器是否重启？
├─ 是（内核崩溃）→ 检查/var/crash（kdump转储）→ 有vmcore→crash工具分析→定位错误模块
│ └─ 无vmcore→开启kdump→复现问题→生成vmcore分析
└─ 否（系统死机）→ 尝试Magic SysRq（t/m命令）→ 收集日志→分析进程/内存异常
└─ 无法收集→配置NMI Watchdog→触发崩溃→生成vmcore分析
→ 软件日志无异常→硬件排查（SEL→磁盘SMART→MCE→内存检测）→ 定位硬件故障
七、常见错误位置及对应解决方案
错误关键词 / 现象
错误位置判定
解决方案
Kernel panic + Call Trace
内核模块 / 驱动冲突、内核漏洞
查看 Call Trace 中的模块名，卸载冲突模块；升级内核到稳定版本
Out of memory (OOM Killer)
内存泄漏、应用占用过高、内存不足
排查内存泄漏进程（ps aux --sort=-%mem）；增加物理内存或交换分区
blk_update_request: I/O error
磁盘坏道、线缆松动、磁盘控制器故障
更换故障磁盘；检查磁盘线缆和控制器；执行 fsck 修复文件系统
soft lockup - CPU#0 stuck
内核死循环、驱动异常
查看 dmesg 中的调用链，升级对应驱动；禁用有问题的内核模块
MCE: Uncorrected Error
CPU 硬件故障
更换故障 CPU；检查主板供电是否正常
SMART Pre-failure
磁盘即将损坏
立即备份数据，更换磁盘
task blocked for 120s
进程死锁、资源耗尽（如锁竞争、IO 阻塞）
查看对应进程的调用栈（pstack 进程PID）；优化应用代码或系统参数
八、附录：常用工具安装命令汇总
工具名称
安装命令
用途
crash
yum install -y crash
分析 vmcore 内核崩溃文件
kdump
yum install -y kdump
捕获内核崩溃转储
sysstat
yum install -y sysstat
系统负载监控（sar 命令）
ipmitool
yum install -y ipmitool
硬件状态检测（SEL 日志）
smartmontools
yum install -y smartmontools
磁盘健康检测（SMART）
mcelog
yum install -y mcelog
CPU 硬件错误日志查看
memstat
yum install -y memstat
内存使用详情监控
