Linux死机问题分析定位.docx

Linux死机问题分析定位.docx

《Linux死机问题分析定位.docx》由会员分享，可在线阅读，更多相关《Linux死机问题分析定位.docx（9页珍藏版）》请在冰点文库上搜索。

文档名称

文档密级

一、现象初步判断：

1、判定是否死机：

首先需要确定是否真正的死机了，而往往有些现象被现场误认为是死机了。

是否死机的确定方法有如下：

A、对于直接死掉的，没有任何反应的情况下，看看键盘输入是否有效，putty是否能够登陆，BMC是否能够登录；

B、通过lastreboot确认是否死机？

死机的时间？

C、通过在messages中对应的时间点看是否有imklog启动的日志？

并在这个时间点前是否收到关机信号或者异常打印？

D、通过在boot.msg中对应时间点有启动的相关记录，并同时查看在boot.omsg中是否有关机的相关日志打印？

搜索：

Shuttingdown关键字看是否存在关机

2、是否人为操作

出现系统重启现象，往往被认为是系统死机后然后重启的，这就通过重启现象了来认为系统死机过，但是这种系统重启是否是由于死机造成的，需要进行确定。

A、通过同现场人员进行沟通，确认是否为人为的重启？

比如按电源、拔电源等人为动作？

B、通过history中查询在系统重启时的时间点附近有reboot或halt、shutdown、init？

C、通过在BMC日志中确认是否有通过BMC的操作进行系统的重启操作？

对于直接拔电源致使系统重启的操作，在messges和boot.omsg中是没有相关的信息记录的，表现为系统日志和业务运行日志在同一时间全部消失。

对于按电源、命令进行重启操作，在messages中能够看到系统收到关机或者重启的信息，同时在boot.omsg中会有关机时的关闭系统服务的关机过程信息。

对于在BMC上直接进行关机或者重启操作，信息记录就比较复杂了。

而对于此种情况，在messages中和boot.omsg中是看不到相关的信息记录，同直接拔电源一样的。

二、处理步骤：

1、日志尽快获取：

在现场反馈出现死机问题后，第一时间反馈相关日志，并尽量多尽量准确全面，等待的时间越长日志可能就已覆盖，或清除，或环境重搭，致使定位工作受到阻碍。

A、死机问题发生的时间点

如果发生死机问题时测试或维护人员在场，需反馈死机问题发生的精确时间。

B、死机具体现象描述

死机问题的发生通常伴随着系统和业务方面的异常现象，系统异常包括服务器重启、系统挂死（如BMC黑屏）、系统迟缓（如命令无法执行或响应时间过长）、网络中断（如Ping检测失败）、登陆失败（如无法远程登陆或卡死在登陆界面）、文件系统异常（如文件只读或系统命令失效）等等；操作失败、超时、执行无返回等。

项目

结果

服务器重启

[OK/NOK]

系统挂死（BMC或KVM黑屏）

[OK/NOK]

系统延缓（如命令无法执行或响应时间过长）

[OK/NOK]

网络中断（如Ping检测失败）

[OK/NOK]

登陆失败（如无法远程登陆或卡死在登陆界面）

[OK/NOK]

文件系统异常（如文件只读或系统命令失效）

[OK/NOK]

业务异常则包括主备HA

[OK/NOK]

操作失败

[OK/NOK]

命令执行超时

[OK/NOK]

此外，同样现象的死机问题是否多次出现、出现频率也需要反馈。

C、死机时段具体操作

主要指死机时段内对整个系统（包括硬件和软件）进行的各种操作，包括但不限于对服务器上下电、更换硬件、拔插网线、更改交换机配置、监控及日志查询。

此外还包括死机之前对问题服务器的各种操作，如执行脚本或系统命令、拷贝/删除/修改文件、启动/停止系统服务、挂载本地或远端目录等。

2.组网、硬件和BMC信息反馈

组网、硬件信息有助于定位人员从宏观把握整个系统以及借鉴之前的经验，而内置在服务器中BMC系统收集的信息有时更能为死机问题定位提供直接的依据。

A、组网信息

组网信息主要包括网络规模（服务器、交换机数目）、硬件类型（防火墙、服务器、交换机型号）、网络配置（IP地址规划、交换机配置）、物理连线图等。

B、硬件信息

硬件信息主要包括发生死机的服务器类型（RH2285、E6000、T6000或其它服务器）、CPU型号与数目、内存大小、本地硬盘容量与数目、BIOS配置等，此外建议信息收集人员尽可能反馈组网内其它服务器、其它设备的硬件信息，便于定位人员横向对比。

服务器各种硬件信息查询如下：

（1）CPU型号与数目

对于管理、存储节点，使用“cat/proc/cpuinfo”命令获得；对于计算节点使用“cat/proc/cpuinfo”仅能获得domain0中的CPU信息，可以通过“xmdmesg”命令查看所有的CPU信息。

（2）内存大小

对于管理、存储节点，使用“cat/proc/meminfo”命令获得；对于计算节点使用“cat/proc/meminfo”仅能获得domain0中的内存信息，可以通过“xmdmesg”命令查看内存总大小。

（3）本地硬盘容量与数目

本地硬盘容量可以通过“fdisk–l”命令获得，考虑RAID组以及挂载远端磁盘的因素，本地硬盘数目最好通过BMC界面直接查看，在BMC界面，系统信息->系统状态中可以看到硬盘槽位和硬盘状态。

3、BMC信息

BMC是公司自研的RH2285、E6000、T6000等型号服务器内嵌的服务器管理控制单元，能够实现对服务器的多种管理、查询、监控功能，发生死机问题时需要从BMC收集的信息包括

（1）BMC系统事件日志

登陆BMC提供的web界面后，查看系统日志事件，反馈死机发生时间点前后一段时间（建议取死机发生前后12小时）的日志截图。

通过ftp方式登陆BMC的文件系统，反馈data目录下的sel.bin文件。

（2）BMC、BIOS版本号

在BMC的web界面，选择系统信息-> 固件版本查询，反馈版本信息：

（3）BMC与OS的时间差

由于BMC和OS使用不同的时间芯片，因此这两者之间可能存在时间差，需要现场人员通过登陆BMC系统和OS进行时间的比对，并截图表示两者之间的时间差异，这样便于定位人员分析BMC日志和OS的日志（时间差）。

三、系统信息

Linux的日志系统能够记录系统的登陆情况、操作记录、异常事件等，多数情况下为系统侧死机问题提供重要的线索，发生死机问题时，建议从系统方面获得如下信息：

1.系统message日志

系统的message日志会记录在cd/var/log/目录下，并根据日志产生时间和日志文件大小压缩备份为“messages-<时间戳>.bz”的形式，请尽可能在反馈全部的日志文件（包括当前日志文件/var/log/messages以及所有的bz压缩文件）。

3、系统boot日志

操作系统能够记录当前和前一次启动时的日志，两次启动记录保存在/var/log/boot.msg和/var/log/boot.omsg中，请全部反馈。

4、系统登录和使用情况

使用last可以查看系统每次启动的时间点、用户登陆情况等，建议使用：

“lastreboot>>last.txt”命令将last命令的执行结果保存为文本文件进行反馈。

5、系统历史操作记录

使用history可以查看系统的历史操作信息，建议使用“history>>history.txt”命令将history命令的执行结果保存为文本文件进行反馈。

6、系统黑匣子记录

系统中提供黑匣子功能收集节点操作系统Crash（如panic、oops、BUG、oom等）时的异常信息，黑匣子功能实现的机制和记录存放位置不同，请注意按照不同的操作系统类型和发生死机的时间反馈对应的黑匣子日志。

系统监控记录

GalaX系统提供对操作系统各种资源进行监控的功能，并生成监控日志保存在每个节点的/opt/osinfo/statistics/目录中，监控日志会根据大小和时间在同一目录下保存为“statistics<时间戳>.tgz”格式，请注意按照发生死机的时间反馈对应的系统监控日志。

A、系统串口消息

如果出于调测的目的开放系统的串口，请反馈问题服务器的串口打印信息，通常情况下GalaX系统中各个节点的串口功能是关闭的。

串口打印的堆栈信息、临终遗言对死机定位非常有用，如果没有部署串口，请尽量将串口部署上，串口信息对于死机问题的定位很重要。

B、底层日志：

C、收集系统的打印信息：

命令：

cat/proc/sys/kernel/printk

1、定位方法

1.是否硬件狗复位

A.在死机问题中，较多的死机问题都是由于软件狗未喂硬件狗，或者喂狗不成功，导致硬件狗超时（超时时间为20Min），从而重启服务器，这样就认为系统死机后的重启。

B.因此查看watchdog的日志，看是否是喂狗的时候出现问题。

首先需要判定是否由于watchdog自身的原因或者某些规则导致硬件狗超时而重启服务器，这样的原因下就是上层业务造成的，不是OS本身的问题。

C.同时在查看watchdog的日志时，注意查看是否是喂狗的脚本执行不成功？

有无及时的返回喂狗脚本执行的结果？

这样判定是否是由于喂狗脚本阻塞引起的硬件狗超时？

同时比对是否在其它的业务模块日志中也有执行脚本不成功的情况？

这样如果所有的模块都存在这种执行脚本不成功、卡死的话，那就不是watchdog本身的原因，而是在系统中的其它原因造成，需要向系统更深入的排查原因了。

如果是由硬件狗复位服务器，在BMC界面日志中能够记录到相应的日志，通过此可以进行判定;

2.是否系统负载过高

Linux系统不是孤立的存在的，其上往往是运行这产品自身的业务，而业务既然使用语言代码编程，那也就存在Bug，而对于这些Bug也可能引起Linux的崩溃或者类似死机的现象。

这类问题往往最常见的现象是系统响应缓慢，或者无法响应，从而认为系统死机，这往往从监控日志中能够看到内存和CPU使用飙高，而这往往是由于系统负载过高导致的。

由于系统负载过高导致的卡死，一定是解决的越快越好！

需要通过命令行终端进行定位。

通过Ctrl＋Alt＋F1（通常F1－F6都可以进行切换），此时可能键盘的输入速度比较慢，请耐性等候，在提示符后输入top回车，看到一张动态的表，上面列出了耗用资源最多的进程。

观察到刷新几次后，按q退出，然后输入killPID，其中PID为top中显示的占用资源较多的进程，此时系统应该会快不少，如果没有结束掉进程，通过kill-9，这样基本上没有问题了（这个动作一般不要做）。

3.是否业务导致

判断到是由于系统的负载过高导致系统的死机，然后就是判定是否是由于业务导致的？

业务模块相对来说是一个比较新开发的，出现问题的几率还是相对来说比较大的。

因此首先是从业务模块下手。

1.在出现问题时，现场是否做了哪些的操作？

2.而这些操作是否会引起某些系统资源的过载使用？

3.结合业务模块的日志，分析在出现问题时是否有某些异常的日志记录？

4.如果有，则找到出现这些异常的原因，向上找到出现这些异常的起始点，再向上查找比较长的时间段日志，看是否有明显的异常。

4.是否硬件相关

因此首先需要同判定现场环境中的BIOS中的某些项的设置是否正确？

看当时配套版本中说明的设置，以及此版本是否本身就存在此问题？

在判定完上述后，如果都不符合，则有可能是出现了新的问题，获取到messages和监控日志等，在其中进行查看是否有报硬件相关的错误，针对这些错误，判断分析是否正常？

而同时这些错误有可能在出现问题之前比较长的时间，需要向上回溯。

需要专业硬件人员来分析。

5.是否内核问题

问题与kernel可能也有关系了，而如果同kernel有较大关系的话，系统会产生kbox文件，而管理节点由于使用LinuxIMG，则产生的黑匣子日志文件在本地/var目录下，计算节点采用的是SmartUVP，则产生的黑匣子日志文件会存放在TFTP服务器上，在GalaX系统中，通常使用MN节点作为TFTP服务器，所以对应计算节点的黑匣子日志保存在MN节点的/tftpboot目录中。

通过黑盒子或者串口信息基本就能确认，需要查看源代码一起分析。

部署串口

串口信息分析:

方法：

Ø通过以上的信息，可以找到具体出问题时的函数，对应到那个模块上，通过对照源码一步步分析堆栈。

Ø上Linux的开源社区搜问题信息，看是否已经有人发现，注意具体的解决方案和版本号。

2023-5-2

华为机密，未经许可不得扩散

第9页,共9页