CN111831520A - 用于Linux操作系统的故障诊断方法及系统 - Google Patents

Abstract

本发明公开了一种用于Linux操作系统的故障诊断方法及系统，涉及Linux操作系统的维护领域。该方法的步骤包括：创建Linux操作系统的内核与外界的数据传输通道，并对数据传输通道进行监听；当监听到从数据传输通道中接收的故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理；故障诊断处理的步骤包括：调用Linux操作系统内核的二层报文处理接口，获取与故障诊断请求对应的二层故障诊断信息后，将二层故障诊断信息通过数据传输通道返回。本发明能够在Linux操作系统出现异常、且其内核可以进行二层数据的传输时，主动获取所需的故障信息，进而对Linux操作系统进行故障诊断。

Description

用于Linux操作系统的故障诊断方法及系统

技术领域

本发明涉及Linux操作系统的维护领域，具体涉及一种用于Linux操作系统的故障诊断方法及系统。

背景技术

在Linux操作系统的应用过程中，经常会遇到因外部硬件的原因导致的异常情况(例如中断异常频繁触发、资源死锁、内核驱动模块异常等)，异常情况的发生会使得Linux操作系统长时间陷入到内核态，进而导致应用程序无法调度，文件系统下的应用服务无法正常运行的假死场景。

在上述假死场景下，因为串口、SSH(Secure Shell，安全外壳协议)、Telnet(远程终端协议)等常用调试工具将无法使用，所以开发调试人员会认定内核的网络不可用，或者内核协议栈不可用；在此基础上，开发调试人员一般只能通过重启查看系统的log日志来分析问题缘由。

但是，开发调试人员只能获取log日志中的错误信息来被动分析问题，这会导致：当Linux操作系统假死的原因不存在log日志中、或者不属于log日志中的错误信息时，即使处理了log日志中错误信息对应的问题，也不会或者无法显著降低Linux操作系统出现假死的概率。

发明内容

针对现有技术中存在的缺陷，本发明解决的技术问题为：在Linux操作系统出现异常、且其内核可以进行二层数据的传输时，如何主动获取所需的故障信息，进而对Linux操作系统进行故障诊断。

为达到以上目的，本发明提供的用于Linux操作系统的故障诊断方法，包括以下步骤：

创建Linux操作系统的内核与外界的数据传输通道，并对数据传输通道进行监听；当监听到从数据传输通道中接收的故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理；所述故障诊断处理的步骤包括：调用Linux操作系统内核的二层报文处理接口，获取与故障诊断请求对应的二层故障诊断信息后，将二层故障诊断信息通过数据传输通道返回。

在上述技术方案的基础上，所述创建Linux操作系统的内核与外界的数据传输通道，并对数据传输通道进行监听；当监听到从数据传输通道中接收的故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：在Linux操作系统启动后，将具备外界信息接收功能的故障信息监听程序加载至Linux操作系统的内核；通过故障信息监听程序向Linux操作系统的内核添加需要监听的故障诊断请求；当故障信息监听程序监听到需要监听的故障诊断请求时，根据故障诊断请求进行故障诊断处理。

在上述技术方案的基础上，所述当故障信息监听程序监听到需要监听的故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：故障信息监听程序按照接收顺序，将所有需要监听的故障诊断请求添加至预先创建于Linux操作系统内核下的故障处理链表中；故障信息监听程序按照故障处理链表中故障诊断请求的排列顺序，依次对故障诊断请求进行故障诊断处理。

在上述技术方案的基础上，该方法还包括以下步骤：

将故障诊断请求通过数据传输通道发送至Linux操作系统的内核，收到Linux操作系统的内核返回的二层故障诊断信息后，将二层故障诊断信息进行解析并显示。

在上述技术方案的基础上，所述调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：

当故障诊断请求为系统内核信息获取时，调用内核的二层报文处理接口获取系统内核信息后返回；

当故障诊断请求为KGDB调试时，触发KGDB功能后返回KGDB调试的调试信息；

当故障诊断请求为系统处理器信息获取时，调用内核的二层报文处理接口获取系统处理器信息后返回；

当故障诊断请求为系统内存信息获取时，调用内核的二层报文处理接口获取系统内存信息后返回；

当故障诊断请求为系统任务信息获取时，调用内核的二层报文处理接口获取系统任务信息后返回；

当故障诊断请求为触发KDUMP时，触发KDUMP后返回KDUMP的触发信息。

本发明提供的用于Linux操作系统的故障诊断系统，包括设置于Linux操作系统上的故障信息监听模块、故障诊断请求接收接口和故障诊断信息发送接口；

故障信息监听模块用于：创建Linux操作系统的内核与外界的数据传输通道，数据传输通道的内核接收端为故障诊断请求接收接口，内核发送端为故障诊断信息发送接口；当监听到故障诊断请求接收接口接收故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理；故障诊断处理的步骤包括：调用Linux操作系统内核的二层报文处理接口，获取与故障诊断请求对应的二层故障诊断信息后，调用故障诊断信息发送接口将二层故障诊断信息通过数据传输通道返回。

在上述技术方案的基础上，所述故障信息监听模块创建Linux操作系统的内核与外界的数据传输通道的工作流程包括：在Linux操作系统启动后加载至Linux操作系统的内核，建立故障诊断请求接收接口及故障诊断信息发送接口，与外界的数据传输通道。

在上述技术方案的基础上，所述故障信息监听模块监听到故障诊断请求接收接口接收故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的工作流程包括：按照接收顺序，将所有需要监听的故障诊断请求添加至预先创建于Linux操作系统内核下的故障处理链表中；按照故障处理链表中故障诊断请求的排列顺序，依次对故障诊断请求进行故障诊断处理。

在上述技术方案的基础上，该系统还包括设置于用户端上的用户诊断模块，其用于：将故障诊断请求发送至故障诊断信息发送接口，收到调用故障诊断信息发送接口返回的二层故障诊断信息后，将二层故障诊断信息进行解析并显示。

在上述技术方案的基础上，所述故障信息监听模块调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：

当故障诊断请求为系统内核信息获取时，调用内核的二层报文处理接口获取系统内核信息后返回；

当故障诊断请求为KGDB调试时，触发KGDB功能后返回KGDB调试的调试信息；

当故障诊断请求为系统处理器信息获取时，调用内核的二层报文处理接口获取系统处理器信息后返回；

当故障诊断请求为系统内存信息获取时，调用内核的二层报文处理接口获取系统内存信息后返回；

当故障诊断请求为系统任务信息获取时，调用内核的二层报文处理接口获取系统任务信息后返回；

当故障诊断请求为触发KDUMP时，触发KDUMP后返回KDUMP的触发信息。

与现有技术相比，本发明的优点在于：

在Linux操作系统出现假死、且其内核可以进行二层数据的传输时，本发明能够通过创建Linux操作系统的内核与外界的数据传输通道的方式，来监听外界的故障诊断请求，并通过内核网络子系统的二层报文处理接口进行数据交互，以此实现对Linux操作系统假死故障的定位与分析。

因此，与现有技术中获取log日志中的错误信息来被动分析问题相比，本发明在Linux操作系统出现异常(例如假死)时，能够让用户主动向Linux操作系统的内核发起故障诊断请求、并进行对应的故障诊断处理，进而显著提高了故障诊断处理的针对性，大幅度降低进行故障诊断处理后的Linux操作系统出现异常的概率。

与此同时，本发明仅在监听到故障诊断请求时，才会进行故障诊断处理，而故障诊断请求一般在Linux操作系统出现异常时发出。因此，本发明在Linux操作系统正常工作时，不会影响Linux操作系统的内核网络协议的运行，便于人们使用。

附图说明

图1为本发明实施例中用户诊断流程的示意图；

图2为本发明实施例中故障信息监听流程的示意图。

具体实施方式

以下结合附图及实施例对本发明作进一步详细说明。

首先介绍本发明实施例中的用于Linux操作系统的故障诊断方法的研发思路：

申请人经过研究得出：在因调试工具无法使用而认定内核网络不可用、或者内核协议栈不可用的大多数场景下，实际上内核下的网络协议栈并没有完全奔溃，只是不能通过三层(网络层)以上的应用服务进行通信。申请人进行思考后得出，在Linux内核下，可以调用帧处理函数对二层(数据链路层)网络协议进行调试与分析，因此内核下的二层报文处理接口成为假死状态下进行网络数据通信的可选通道。

在此基础上，申请人经过继续研究得到了后续的用于Linux操作系统的故障诊断方法；要说明的是：上述研究得出的思考信息是属于本发明创新的一部分，因为在本申请以前，没有文献提到或者公开了上述的研究信息。

进一步，即使本领域普通技术人员能够想到将内核下的二层报文处理接口成为假死状态下进行网络数据通信的可选通道，也会存在以下问题：

1、一般的系统状态监控，是在用户态通过文件系统接口调用系统接口，来收集系统状态(例如进程资源、内核使用率等信息)的，但在系统假死下，文件系统接口可能已经不可用了，所以无法通过文件系统接口来收集信息。

2、一般使用KDUMP工具(在系统崩溃、死锁或者死机的时候用来转储内存运行参数的一个工具和服务)对内核进行调试，但KDUMP工具为被动触发，因此目前在系统假死时无法触发KDUMP工具。

因此，只有想到了上述研究得出的思考信息以及存在的问题，才有可能得出本发明的方法。

在此基础上，本发明实施例中的用于Linux操作系统的故障诊断方法，包括以下步骤：

故障信息监听流程：创建Linux操作系统的内核与外界的数据传输通道，并对数据传输通道进行监听；当监听到从数据传输通道中接收的故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理；故障诊断处理的步骤包括：调用Linux操作系统内核的二层报文处理接口，获取与故障诊断请求对应的二层故障诊断信息后，将二层故障诊断信息通过数据传输通道返回。

从上文可知，在Linux操作系统出现假死、且其内核可以进行二层数据的传输时，本发明能够通过创建Linux操作系统的内核与外界的数据传输通道的方式，来监听外界的故障诊断请求，并通过内核网络子系统的二层报文处理接口进行数据交互，以此实现对Linux操作系统假死故障的定位与分析。

因此，与现有技术中获取log日志中的错误信息来被动分析问题相比，本发明在Linux操作系统出现异常(例如假死)时，能够让用户主动向Linux操作系统的内核发起故障诊断请求、并进行对应的故障诊断处理，进而显著提高了故障诊断处理的针对性，大幅度降低进行故障诊断处理后的Linux操作系统出现异常的概率。

与此同时，参见上文可知，本发明仅在监听到故障诊断请求时，才会进行故障诊断处理，而故障诊断请求一般在Linux操作系统出现异常时发出。因此，本发明在Linux操作系统正常工作时，不会影响Linux操作系统的内核网络协议的运行，便于人们使用。

优选的，该方法具体包括以下流程：在Linux操作系统启动、且工作正常时后，将具备外界信息接收功能的故障信息监听程序加载至Linux操作系统的内核(故障信息监听程序一般在预出场时已经设置，加载故障信息监听程序则意味着已经建立数据传输通道)；通过故障信息监听程序向Linux操作系统的内核协议栈添加需要监听的故障诊断请求；当故障信息监听程序监听到需要监听的故障诊断请求时，根据故障诊断请求进行故障诊断处理。

可知，在上文提到了故障信息监听程序具备外界信息接收功能、能够加载至Linux操作系统的内核、且故障诊断处理的步骤的基础上，本领域普通技术人员能够根据本领域公知常识来设计符合上述功能的故障信息监听程序。

优选的，当故障信息监听程序监听到需要监听的故障诊断请求时，根据故障诊断请求进行故障诊断处理的流程包括：故障信息监听程序按照接收顺序，将所有需要监听的故障诊断请求添加至预先创建于Linux操作系统内核下的故障处理链表中；故障信息监听程序按照故障处理链表中故障诊断请求的排列顺序，依次对故障诊断请求进行故障诊断处理。

由此可知，本发明能够通过链表排序的方式，有序的对需要监听的故障诊断请求进行处理，进而优化了故障诊断处理流程，避免了因并行处理多个故障诊断请求而造成的信息堵塞或者系统混乱。

优选的，该方法还包括以下步骤：

用户诊断流程：将故障诊断请求通过数据传输通道发送至Linux操作系统的内核，收到Linux操作系统的内核返回的二层故障诊断信息后，将二层故障诊断信息进行解析并显示。

优选的，所述根据故障诊断请求进行故障诊断处理的流程包括：

当故障诊断请求为系统内核信息获取时，调用内核的二层报文处理接口获取系统内核信息后返回，此时该信息即为二层故障诊断信息；

当故障诊断请求为KGDB调试时，触发KGDB功能后返回KGDB调试的调试信息，此时该信息即为二层故障诊断信息；

当故障诊断请求为系统处理器信息获取时，调用内核的二层报文处理接口获取系统处理器信息后返回，此时该信息即为二层故障诊断信息；

当故障诊断请求为系统内存信息获取时，调用内核的二层报文处理接口获取系统内存信息后返回，此时该信息即为二层故障诊断信息；

当故障诊断请求为系统任务信息(系统任务处理器、系统任务内存、系统任务处理栈)获取时，调用内核的二层报文处理接口获取系统任务信息后返回，此时该信息即为二层故障诊断信息；

当故障诊断请求为触发KDUMP时，触发KDUMP后返回KDUMP的触发信息(例如KDUMP触发成功或者失败)，此时该信息即为二层故障诊断信息。

下面，通过一个具体实施例说明本发明的方法。

参见图1所示，用户诊断流程包括：

S101：用户在与Linux操作系统同一网段的终端(该终端的操作系统可以为Linux系统或者windows系统)上，通过一个可视化的操作界面发起故障诊断命令(可以在操作界面上直接点击对应的功能)，转到S102。

S102：通过用户态线程将故障诊断命令转换为与Linux操作系统的内核对应的用户私有帧(即故障诊断请求)后，发送至Linux操作系统的内核的故障信息监听程序，转到S103。

S103：判断是否在超时时间内收到故障信息监听程序返回的内核私有帧(即二层故障诊断信息)，若是，转到S104，否则重新执行S101。

S104：解析内核私有帧中的数据后，根据数据内容进行显示。

参见图2所示，故障信息监听流程包括：

S201：故障信息监听程序的初始化：在Linux操作系统启动、且工作正常时后，将具备外界信息接收功能的故障信息监听程序加载至Linux操作系统的内核；通过故障信息监听程序向Linux操作系统的内核协议栈添加需要监听的故障诊断请求(即packet结构体)、并创建Linux操作系统的内核下的故障处理链表，转到S202。

S202：故障信息监听程序判断是否接收到用户私有帧，若是，转到S203，否则处于不激活状态(接收用户私有帧属于被动触发故障信息监听程序，不需要激活该程序)，重新执行S202。

S203：当用户私有帧对应的数据属于S201中添加的需要监听的故障诊断请求时，按照接收顺序将用户私有帧添加至故障处理链表，转到S204。

S204：按照故障处理链表中故障诊断请求的排列顺序，依次对用户私有帧进行故障诊断处理，故障诊断处理的流程包括：

当故障诊断请求为系统内核信息获取时，调用内核的二层报文处理接口获取系统内核信息后返回，此时该信息即为内核私有帧；

当故障诊断请求为KGDB调试时，触发KGDB功能后返回KGDB调试的调试信息，此时该信息即为内核私有帧；

当故障诊断请求为系统处理器信息获取时，调用内核的二层报文处理接口获取系统处理器信息后返回，此时该信息即为内核私有帧；

当故障诊断请求为系统内存信息获取时，调用内核的二层报文处理接口获取系统内存信息后返回，此时该信息即为内核私有帧；

当故障诊断请求为系统任务信息(系统任务处理器、系统任务内存、系统任务处理栈)获取时，调用内核的二层报文处理接口获取系统任务信息后返回，此时该信息即为内核私有帧；

当故障诊断请求为触发KDUMP时，触发KDUMP后返回KDUMP的触发信息(例如KDUMP触发成功或者失败)，此时该信息即为内核私有帧。

下面说明本发明的具体应用场景和应用结果。

在某项目中，调试交换芯片过程中出现CPU挂死现象，但网口可以Ping通，即内核网络子系统是正常的；使用本发明的故障诊断方法后，用户可获取到部分CPU信息，发现此时CPU系统占用率很高，CPU中断系统出现异常；进而初步诊断为PCIE(PeripheralComponent Interconnect Express，一种高速串行计算机扩展总线)的MSI中断导致CPU异常。按照此信息，最终发现内核的bug，完成对该挂死问题的诊断与定位。

本发明实施例中的用于Linux操作系统的故障诊断系统，包括设置于Linux操作系统上的故障信息监听模块、故障诊断请求接收接口和故障诊断信息发送接口；还包括设置于用户端上的用户诊断模块。

故障信息监听模块用于：创建Linux操作系统的内核与外界的数据传输通道，数据传输通道的内核接收端为故障诊断请求接收接口，内核发送端为故障诊断信息发送接口；当监听到故障诊断请求接收接口接收故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理；故障诊断处理的步骤包括：调用Linux操作系统内核的二层报文处理接口，获取与故障诊断请求对应的二层故障诊断信息后，调用故障诊断信息发送接口将二层故障诊断信息通过数据传输通道返回。

故障信息监听模块创建Linux操作系统的内核与外界的数据传输通道的工作流程包括：在Linux操作系统启动后加载至Linux操作系统的内核，建立故障诊断请求接收接口及故障诊断信息发送接口，与外界的数据传输通道。

故障信息监听模块监听到故障诊断请求接收接口接收故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的工作流程包括：按照接收顺序，将所有需要监听的故障诊断请求添加至预先创建于Linux操作系统内核下的故障处理链表中；按照故障处理链表中故障诊断请求的排列顺序，依次对故障诊断请求进行故障诊断处理。

故障信息监听模块调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：

当故障诊断请求为系统内核信息获取时，调用内核的二层报文处理接口获取系统内核信息后返回；

当故障诊断请求为KGDB调试时，触发KGDB功能后返回KGDB调试的调试信息；

当故障诊断请求为系统处理器信息获取时，调用内核的二层报文处理接口获取系统处理器信息后返回；

当故障诊断请求为系统内存信息获取时，调用内核的二层报文处理接口获取系统内存信息后返回；

当故障诊断请求为系统任务信息获取时，调用内核的二层报文处理接口获取系统任务信息后返回；

当故障诊断请求为触发KDUMP时，触发KDUMP后返回KDUMP的触发信息。

用户诊断模块用于：将故障诊断请求发送至故障诊断信息发送接口，收到调用故障诊断信息发送接口返回的二层故障诊断信息后，将二层故障诊断信息进行解析并显示。

需要说明的是：本发明实施例提供的系统在进行模块间通信时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

进一步，本发明不局限于上述实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims (10)

1.一种用于Linux操作系统的故障诊断方法，其特征在于，该方法包括以下步骤：

创建Linux操作系统的内核与外界的数据传输通道，并对数据传输通道进行监听；当监听到从数据传输通道中接收的故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理；所述故障诊断处理的步骤包括：调用Linux操作系统内核的二层报文处理接口，获取与故障诊断请求对应的二层故障诊断信息后，将二层故障诊断信息通过数据传输通道返回。

2.如权利要求1所述的用于Linux操作系统的故障诊断方法，其特征在于，所述创建Linux操作系统的内核与外界的数据传输通道，并对数据传输通道进行监听；当监听到从数据传输通道中接收的故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：在Linux操作系统启动后，将具备外界信息接收功能的故障信息监听程序加载至Linux操作系统的内核；通过故障信息监听程序向Linux操作系统的内核添加需要监听的故障诊断请求；当故障信息监听程序监听到需要监听的故障诊断请求时，根据故障诊断请求进行故障诊断处理。

3.如权利要求2所述的用于Linux操作系统的故障诊断方法，其特征在于：所述当故障信息监听程序监听到需要监听的故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：故障信息监听程序按照接收顺序，将所有需要监听的故障诊断请求添加至预先创建于Linux操作系统内核下的故障处理链表中；故障信息监听程序按照故障处理链表中故障诊断请求的排列顺序，依次对故障诊断请求进行故障诊断处理。

4.如权利要求1所述的用于Linux操作系统的故障诊断方法，其特征在于，该方法还包括以下步骤：

将故障诊断请求通过数据传输通道发送至Linux操作系统的内核，收到Linux操作系统的内核返回的二层故障诊断信息后，将二层故障诊断信息进行解析并显示。

5.如权利要求1至4任一项所述的用于Linux操作系统的故障诊断方法，其特征在于，所述调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：

当故障诊断请求为系统内核信息获取时，调用内核的二层报文处理接口获取系统内核信息后返回；

当故障诊断请求为KGDB调试时，触发KGDB功能后返回KGDB调试的调试信息；

当故障诊断请求为系统处理器信息获取时，调用内核的二层报文处理接口获取系统处理器信息后返回；

当故障诊断请求为系统内存信息获取时，调用内核的二层报文处理接口获取系统内存信息后返回；

当故障诊断请求为系统任务信息获取时，调用内核的二层报文处理接口获取系统任务信息后返回；

当故障诊断请求为触发KDUMP时，触发KDUMP后返回KDUMP的触发信息。

6.一种用于Linux操作系统的故障诊断系统，其特征在于：该系统包括设置于Linux操作系统上的故障信息监听模块、故障诊断请求接收接口和故障诊断信息发送接口；

故障信息监听模块用于：创建Linux操作系统的内核与外界的数据传输通道，数据传输通道的内核接收端为故障诊断请求接收接口，内核发送端为故障诊断信息发送接口；当监听到故障诊断请求接收接口接收故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理；故障诊断处理的步骤包括：调用Linux操作系统内核的二层报文处理接口，获取与故障诊断请求对应的二层故障诊断信息后，调用故障诊断信息发送接口将二层故障诊断信息通过数据传输通道返回。

7.如权利要求6所述的用于Linux操作系统的故障诊断系统，其特征在于：所述故障信息监听模块创建Linux操作系统的内核与外界的数据传输通道的工作流程包括：在Linux操作系统启动后加载至Linux操作系统的内核，建立故障诊断请求接收接口及故障诊断信息发送接口，与外界的数据传输通道。

8.如权利要求6所述的用于Linux操作系统的故障诊断系统，其特征在于：所述故障信息监听模块监听到故障诊断请求接收接口接收故障诊断请求时，调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的工作流程包括：按照接收顺序，将所有需要监听的故障诊断请求添加至预先创建于Linux操作系统内核下的故障处理链表中；按照故障处理链表中故障诊断请求的排列顺序，依次对故障诊断请求进行故障诊断处理。

9.如权利要求6所述的用于Linux操作系统的故障诊断系统，其特征在于：该系统还包括设置于用户端上的用户诊断模块，其用于：将故障诊断请求发送至故障诊断信息发送接口，收到调用故障诊断信息发送接口返回的二层故障诊断信息后，将二层故障诊断信息进行解析并显示。

10.如权利要求6至9任一项所述的用于Linux操作系统的故障诊断系统，其特征在于，所述故障信息监听模块调用Linux操作系统的内核根据故障诊断请求进行故障诊断处理的流程包括：

当故障诊断请求为系统内核信息获取时，调用内核的二层报文处理接口获取系统内核信息后返回；

当故障诊断请求为KGDB调试时，触发KGDB功能后返回KGDB调试的调试信息；

当故障诊断请求为系统处理器信息获取时，调用内核的二层报文处理接口获取系统处理器信息后返回；

当故障诊断请求为系统内存信息获取时，调用内核的二层报文处理接口获取系统内存信息后返回；

当故障诊断请求为系统任务信息获取时，调用内核的二层报文处理接口获取系统任务信息后返回；

当故障诊断请求为触发KDUMP时，触发KDUMP后返回KDUMP的触发信息。

Images