25.4. 检测软件问题
ABRT 能够在以各种编程语言编写的应用中检测、分析和处理崩溃。当安装其中一个主要 ABRT 软件包(brt-desktop,abr t-cli)时, 系统会自动安装许多包含检测各种崩溃类型的软件包。有关如何安装 ABRT 的说明,请参阅 第 25.2 节 “安装 ABRT 并启动其服务”。下表中列出了受支持的崩溃类型和相应的软件包。
Langauge/Project | 软件包 |
---|---|
c 或 C++ | abrt-addon-ccpp |
Python | abrt-addon-python |
Ruby | rubygem-abrt |
Java | abrt-java-connector |
X.Org | abrt-addon-xorg |
Linux(内核oops) | abrt-addon-kerneloops |
Linux(内核 panic) | abrt-addon-vmcore |
Linux(永久存储) | abrt-addon-pstoreoops |
25.4.1. 检测 C 和 C++ Crashes
abrt-ccpp
服务安装自己的核心转储处理程序,当启动时,会覆盖内核的 core_pattern
变量的默认值,以便 C 和 C++ 崩溃由 abrtd 处理
。如果您停止 abrt-ccpp
服务,则之前指定的 core_pattern
值会被恢复。
默认情况下,/proc/sys/kernel/core_pattern
文件包含字符串 core
,这意味着内核会在崩溃进程的当前目录中生成 core. 前缀
的文件。abrt-ccpp
服务覆盖 core_pattern
文件,使其包含以下命令:
|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
该命令指示内核将内核转储传送到 abrt-hook-ccpp
程序,该程序将其保存在 ABRT的转储位置,并通知新崩溃的缩写守护进程
。它还存储 /proc/PID / 目录(其中 PID
是崩溃进程的 ID)中的以下文件以进行调试: map
、限制、c
groups、
状态
。有关这些文件的格式和含义的说明,请参见 proc(5)。
25.4.2. 检测 Python 例外
abrt-addon-python 软件包为 Python 应用安装自定义异常处理程序。然后,Py th 解释器会自动导入
文件,该文件又导入 /usr/lib64/python2.7/site-packages/
中安装的 abrt.pthabrt_exception_handler.py
。这会使用自定义处理程序覆盖 Python 的默认 sys.excepthook
,它将未处理的异常通过 Socket API 转发到 abrtd
。
要禁用特定于站点的模块的自动导入,并防止在运行 Python 应用程序时使用 ABRT 自定义异常处理器,将 -S
选项传递给 Python 解释器:
~]$ python -S file.py
在以上命令中,将 file.py 替换为您要执行的 Python 脚本的名称,而不使用特定于站点的模块。
25.4.3. 检测 Ruby Exceptions
rubygem-abrt 软件包使用 at_exit
功能注册自定义处理程序,该功能在程序结束时执行。这样便可检查可能的未处理异常。每次捕获未处理异常时,ABRT 处理程序都会准备一个错误报告,可使用标准 ABRT 工具将其提交到红帽 Bugzilla。
25.4.4. 检测 Java 例外
ABRT Java Connector 是一个 JVM 代理,它报告 无法破碎的 Java
异常。代理注册了多个 JVMTI 事件回调,必须使用 -agentlib
命令行参数加载到 JVM 中。请注意,注册回调的处理会对应用程序的性能造成负面影响。使用以下命令,使 ABRT 捕获来自 Java 类的异常:
~]$ java -agentlib:abrt-java-connector=abrt=on $MyClass -platform.jvmtiSupported true
在上面的命令中,将 $MyClass 替换为您要测试的 Java 类的名称。通过将 abrt=on
选项传递给连接器,您可以确保由 abrtd
处理异常。如果您希望连接器将异常输出到标准输出,请省略这个选项。
25.4.5. 检测 X.Org Crashes
abrt-xorg
服务从 /var/log/Xorg.0.log 文件中收集并处理有关 X.Org 服务器
崩溃的信息。请注意,如果加载了黑名单 X.org 模块,则不会生成报告。相反,会在 问题数据目录中创建一个不可报告的文件
,并给出相应的说明。您可以在 /etc/abrt/plugins/xorg.conf
文件中找到出错模块列表。默认情况下,只有专有图形驱动程序模块才会列入黑名单。
25.4.6. 检测内核 Oopses 和 Panics
通过检查内核日志的输出,ABRT 可以捕获和处理所谓的内核oopses - 非严重偏差于 Linux 内核的正确行为。此功能由 abrt-oops
服务提供。
ABRT 还可以使用 abrt-vmcore
服务检测和处理内核 panics - 需要重新启动的严重、不可恢复的错误。仅当 vmcore
文件(内核转储)显示在 /var/crash/
目录中时,服务才会启动。找到 core-dump 文件时,abr t-vmcore
在
目录,并将 core-dump 文件复制到新创建的 issue-data 目录中。搜索 /var/spool/abrt/
目录中创建一个新的问题数据/var/crash/
目录后,服务将停止。
要使 ABRT 能够检测到内核 panic,必须在系统中启用 kdump
服务。为 kdump 内核保留的内存量必须正确设置。您可以使用 system -config-kdump 图形工具进行设置,或在 GRUB 2 菜单的内核选项列表中指定 crashkernel
参数。有关如何启用和配置 kdump
的详情,请参考 Red Hat Enterprise Linux 7 内核崩溃转储指南。有关对 GRUB 2 菜单进行更改的详情请参考 第 26 章 使用 GRUB 2。
通过使用 abrt-pstoreoops
服务,ABRT 能够收集和处理有关内核 panic 的信息,这些信息存储在支持 pstore 的系统上,存储在自动挂载的 /sys/fs/pstore/
目录中。依赖于平台的 pstore 接口(持久存储)提供了一种在系统重启后存储数据的机制,从而允许保留内核 panic 信息。当内核崩溃转储文件出现在 /sys/fs/pstore/
目录中时,服务会自动启动。