25.3. 配置 ABRT
问题生命周期由 ABRT 中的事件 驱动。例如：
- 事件 #1 - 已创建一个问题数据目录。
- 事件 #2 - 问题数据被分析。
- 事件 #3 - 问题报告至 Bugzilla。
每当检测到问题时，ABRT 会将其与所有现有的问题数据进行比较，并确定是否已经记录了同样的问题。如果存在，则对现有问题数据进行更新，并且不再记录最新的（重复数据删除）问题。如果 ABRT 无法识别 该问题，则会创建一个问题数据目录。问题数据目录通常由以下文件组成： 分析器、架构、核心转储、 cmdline、可执行文件、内核、os_release、原因、时间和 uid。
根据使用了分析器方法及其配置设置，可以在分析问题时创建 回溯追踪 等其他文件。每个文件都包含有关系统和问题本身的特定信息。例如，内核 文件记录了崩溃内核的版本。
创建问题数据目录并收集问题后，您可以使用 ABRT GUI 或命令行 abrt-cli 实用程序来解决问题。有关处理记录问题的 ABRT 工具的更多信息，请参阅 第 25.5 节 “处理检测到的问题”。
25.3.1. 配置事件
ABRT 事件使用 插件 来执行实际的报告操作。插件是处理问题数据目录内容的事件调用的紧凑实用程序。通过使用插件，ABRT 能够向不同目的地报告问题，几乎每个报告目的地都需要进行一些配置。例如，Bugzilla 需要用户名、密码和指向 Bugzilla 服务的 URL。
有些配置详情可以具有默认值（如 Bugzilla URL），但其他配置详情不具有明智的默认值（如用户名）。ABRT 在 /etc/libreport/events/ 或 $HOME/ .cache/abrt/events/ 中分别查找配置文件（如 report_Bugzilla.conf ）或$HOME/.cache/abrt/events/ 目录，分别用于系统范围或用户特定的设置。配置文件包含指令和值对。
这些文件是运行事件和处理问题数据目录所需的最低程度。The gnome-abrt 和 abrt-cli 工具从这些文件中读取配置数据，并将其传递到其运行的事件。
有关事件的其他信息（如描述、名称、可作为环境变量传递的参数类型和其他属性）存储在 /usr/share/libreport/events/ 目录中的 event_name.xml 文件中。这些文件由 gnome-abrt 和 abrt-cli 使用，使用户界面更易理解。除非要修改标准安装，否则请不要编辑这些文件。如果要执行此操作，请将要修改的文件复制到 /etc/libreport/events/ 目录并修改新文件。这些文件可包含以下信息：
- 用户友好的事件名称和描述（Bugzilla，报告至 Bugzilla 错误跟踪器）
- 事件成功所需的问题数据目录中项目列表。
- 默认和强制选择要发送的项目，
- GUI 是否应该提示进行数据审核，
- 存在哪些配置选项，其类型（字符串、布尔值等）、默认值、提示字符串等；这允许 GUI 构建适当的配置对话框。
例如，report_Logger 事件接受输出文件名作为参数。使用对应的 event_name.xml 文件，ABRT GUI 确定可以为所选事件指定哪些参数，并允许用户为这些参数设置值。这些值由 ABRT GUI 保存，并在这些事件的后续调用中重复使用。请注意，ABRT GUI 使用 GNOME 密钥环 工具保存配置选项，并通过将它们传递给事件来覆盖文本文件中的数据。
要打开图形 配置 窗口，请在 gnome-abrt 应用程序的 正在运行的实例中选择
图 25.1. 配置 ABRT 事件
/etc/libreport/ 目录层次结构中的所有文件都是全局可读的，旨在用作全局设置。因此，不建议将用户名、密码或任何其他敏感数据存储在其中。每个用户设置（在 GUI 应用中设置并由 $HOME 的所有者唯一可读）安全存储在 GNOME 密钥环 中，或者可以存储在 $HOME/.abrt/ 中的文本文件中，以用于 abrt-cli。
下表显示了由标准安装 ABRT 提供的默认分析、收集和报告事件选择。表列出了 /etc/libreport/events.d/ 目录中的各个事件的名称、标识符、配置文件，以及一个简短描述。请注意，虽然配置文件使用事件标识符，但 ABRT GUI 使用它们的名称来指代各个事件。另请注意，并非所有事件都可使用 GUI 进行设置。有关如何定义自定义事件的详情请参考 第 25.3.2 节 “创建自定义事件”。
| 名称 | 标识符和配置文件 | 描述 |
|---|---|---|
| uReport | report_uReport | 将 ⋮Report 上传到 FAF 服务器。 |
| mailx | report_Mailx
| 通过 Mailx 实用程序将问题报告发送到指定的电子邮件地址。 |
| Bugzilla | report_Bugzilla
| 向 Bugzilla 错误跟踪程序指定的安装报告问题。 |
| 红帽客户支持 | report_RHTSupport
| 向红帽技术支持系统报告问题。 |
| 分析 C 或 C++ Crash | analyze_CCpp
| 将核心转储发送到远程回溯服务器进行分析，或者在远程分析失败时执行本地分析。 |
| 报告上传程序 | report_Uploader
|
使用 |
| 分析 VM 内核 | analyze_VMcore
|
针对内核oops 问题数据运行 GDB （GNU 调试器），并生成内核 |
| 本地 GNU 调试器 | analyze_LocalGDB
|
对应用的问题数据运行 GDB （GNU 调试器），并为程序生成 |
| 收集 .xsession-errors | analyze_xsession_errors
|
将 |
| 日志记录器 | report_Logger
| 创建问题报告并将其保存到指定的本地文件中。 |
| Kerneloops.org | report_Kerneloops
| 将内核问题发送到 kerneloops.org 上的 oops 跟踪器。 |
25.3.2. 创建自定义事件
每个事件都通过对应配置文件中的一个规则结构来定义。配置文件通常存储在 /etc/libreport/events.d/ 目录中。这些配置文件由主配置文件 /etc/libreport/report_event.conf 加载。不需要编辑默认配置文件，因为 abrt 将运行 /etc/libreport/events.d/ 中包含的脚本。此文件接受 shell 元字符（如 *、$、？）并且相对路径相对路径相对其位置。
每个 规则 以非空格前字符的行开头，并以 空格 字符或 制表符 开头的所有后续行都被视为此规则的一部分。每个规则由两个部分组成 ，一个条件部分和程序 部分。条件部分包含以下形式之一的条件：
- VAR=VAL
- VAR!=VAL
- VAL~=REGEX
其中：
-
VAR 可以是 EVENT 关键字，也可以是问题数据目录元素的名称（如
可执行文件、软件包、主机名等） - VAL 是事件的名称或问题数据元素，以及
- REGEX 是正则表达式。
程序部分由程序名称和 shell 可解读代码组成。如果条件部分中的所有条件都有效，程序部分将在 shell 中运行。以下是事件示例 ：
EVENT=post-create date > /tmp/dt
echo $HOSTNAME uname -r
此事件会用当前日期和时间覆盖 /tmp/dt 文件的内容，并在标准输出中打印计算机的主机名及其内核版本。
以下是更加复杂的事件的示例，实际上是预定义事件之一。它将 ~/.xsession-errors 文件中的相关行保存到使用 abrt-ccpp 服务的问题报告中，前提是崩溃的应用程序在崩溃时载入了任何 X11 库：
EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=./libX11.
test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }
test -r ~/.xsession-errors || { echo "Can't read ~/.xsession-errors"; exit 1; }
executable=cat executable &&
base_executable=${executable##*/} &&
grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
echo "Element 'xsession_errors' saved"
组可能的事件并不确定。系统管理员可以根据自己需要在 /etc/libreport/events.d/ 目录中添加事件。
目前，标准 ABRT 和 libreport 安装会提供以下事件名称：
post-create-
此事件由
abrtd运行，以处理新创建的问题数据目录。当创建后事件运行时，abrtd会检查新问题数据是否与任何已存在的问题目录匹配。如果存在此类问题目录，则会更新，并丢弃新问题数据。请注意，如果创建后事件中的任何定义中的脚本都以非零值退出，则abrtd将终止进程并丢弃问题数据。 notify,notify-dup-
notify事件在创建后运行。当事件运行时，用户可以确保问题吸引了他们的关注。notify-dup类似，但用于同一问题的重复发生。 analyze_name_suffix-
其中 name_suffix 是事件名称的可替换部分。此事件用于处理收集的数据。例如，s
ights_LocalGDB事件使用 GNU Debugger(GDB)实用程序来处理应用的核心转储并生成崩溃的回溯追踪。 collect_name_suffix{blank}… 其中 name_suffix 是事件名称的可调整部分。此事件用于收集有关问题的其他信息。
report_name_suffix{blank}… 其中 name_suffix 是事件名称的可调整部分。此事件用于报告问题。
25.3.3. 设置自动报告
ABRT 可以配置为在不用户交互的情况下自动发送任何检测到的问题或自动崩溃的初始匿名报告或仅发送 一个匿名报告。当打开自动报告时，通常在检测到崩溃报告过程开始时发送名为 ¹Report 的名为 ¹Report。这可防止基于相同崩溃的重复支持案例。要启用自动报告功能，以 root 用户身份运行以下命令：
~]# abrt-auto-reporting enabled
以上命令将 /etc/abrt/abrt.conf 配置文件中的 AutoreportingEnabled 指令设置为 yes。此系统范围设置适用于系统的所有用户。请注意，通过启用此选项，图形桌面环境中也将启用自动报告功能。要在 ABRT GUI 中启用自动报告，请在 问题报告配置 窗口中将 Automatically send uReport 选项切换到 YES。要打开此窗口，请 从 gnome-abrt 应用程序的正在运行的实例中选择
图 25.2. 配置 ABRT 问题报告
默认情况下，在检测到崩溃后，ABRT 会向红帽的 ABRT 服务器提交有关该问题的基本信息。服务器确定问题是否已知，提供问题的简短描述，并提供所报告案例的 URL （如果已知）或者要求用户报告问题（如果未知）。
□Report(microreport)是一个代表问题的 JSON 对象，如二进制崩溃或内核 oops。报告设计为简略、计算机可读且完全匿名，这就是为什么它们可用于自动报告的原因。⋮Reports 可以跟踪错误的发生，但它们通常不会为工程师提供足够的信息来修复这个程序错误。需要一个完整的错误报告才可以打开支持问题单。
要更改自动报告功能的默认行为发送 ›Report，修改 /etc/abrt/abrt.conf 配置文件中的 AutoreportingEvent 指令的值，使其指向不同的 ABRT 事件。有关标准事件的概述请查看 表 25.1 “标准 ABRT 事件”。
