搜索

25.4. 检测软件问题

download PDF

ABRT 能够在以各种编程语言编写的应用中检测、分析和处理崩溃。当安装其中一个主要 ABRT 软件包(brt-desktop,abr t-cli)时, 系统会自动安装许多包含检测各种崩溃类型的软件包。有关如何安装 ABRT 的说明,请参阅 第 25.2 节 “安装 ABRT 并启动其服务”。下表中列出了受支持的崩溃类型和相应的软件包。

表 25.2. 支持的编程语言和软件项目
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.pth 文件,该文件又导入 abrt_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 /var/spool/abrt/ 目录中创建一个新的问题数据 目录,并将 core-dump 文件复制到新创建的 issue-data 目录中。搜索 /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/ 目录中时,服务会自动启动。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.