配置

配置文件

安装后，ABRT和libreport将各自的配置文件放在系统上的几个目录中：

/etc/libreport/

包含 report_event.conf 主配置文件。有关此配置文件的详细信息，请参阅 事件配置 .

/etc/libreport/events/

保存指定预定义事件的默认设置的文件。

/etc/libreport/events.d/

保留定义事件的配置文件。

/etc/libreport/plugins/

包含参与事件的程序的配置文件。

/etc/abrt/

保存用于修改ABRT服务和程序行为的ABRT特定配置文件。有关某些特定配置文件的详细信息，请参阅 ABRT特定配置 .

/etc/abrt/plugins/

保留用于覆盖ABRT服务和程序的默认设置的配置文件。有关某些特定配置文件的更多信息，请参阅 ABRT特定配置 .

配置文件需要用等号分隔的键值对。不支持引用值。

ABRT特定配置

标准ABRT安装目前提供以下特定于ABRT的配置文件：

/etc/abrt/abrt.conf

允许您修改abrtd服务的行为。

/etc/abrt/abrt-action-save-package-data.conf

允许您修改abrt action save package data程序的行为。

/etc/abrt/plugins/CCpp.conf

允许您修改ABRT的核心钩子的行为。

中支持以下配置指令 /etc/abrt/abrt.conf 文件：

  • WatchCrashdumpArchiveDir = /var/spool/abrt-upload

如果需要，请启用此指令 abrtd 自动解包crashdump tarball档案 (.tar.gz )位于指定目录中的。在上面的例子中，它是 /var/spool/abrt-upload/ 目录。无论您在这个指令中指定哪个目录，您都必须确保它存在并且对于abrtd是可写的。ABRT守护进程不会自动创建它。如果更改此选项的默认值，请注意，为了确保ABRT的正确功能，此目录 不能 与为指定的目录相同 DumpLocation 选择权。

小心

使用SELinux时不要修改此选项

更改crashdump存档的位置将导致SELinux拒绝，除非您首先在相应的SELinux规则中反映更改。看到了吗 abrt_selinux(8) 有关在SELinux中运行ABRT的更多信息，请参阅手册页。

请记住，如果在使用SELinux时启用此选项，则需要执行以下命令以设置适当的SELinux布尔值，从而允许ABRT写入 public_content_rw_t 域：：

setsebool -P abrt_anon_write 1

  • MaxCrashReportsSize = size_in_mebibytes

此选项设置ABRT用于存储所有用户的所有问题信息的存储空间量（以兆字节为单位）。默认设置为5000 MiB。一旦达到此处指定的配额，ABRT将继续捕获问题，并且为了为新的崩溃转储腾出空间，它将删除最旧和最大的崩溃转储。

  • DumpLocation = /var/spool/abrt

此指令指定创建问题数据目录的位置，以及存储问题核心转储和所有其他问题数据的位置。默认位置设置为 /var/spool/abrt 目录。无论您在这个指令中指定哪个目录，您都必须确保它存在并且可以为其写入 abrtd . 如果更改此选项的默认值，请注意，为了确保ABRT的正确功能，此目录 不能 与为指定的目录相同 WatchCrashdumpArchiveDir 选择权。

小心

使用SELinux时不要修改此选项

更改转储位置将导致SELinux拒绝，除非您首先在相应的SELinux规则中反映更改。看到了吗 abrt_selinux(8) 有关在SELinux中运行ABRT的更多信息，请参阅手册页。

请记住，如果在使用SELinux时启用此选项，则需要执行以下命令以设置适当的SELinux布尔值，从而允许ABRT写入 public_content_rw_t 域：：

setsebool -P abrt_anon_write 1

中支持以下配置指令 /etc/abrt/abrt-action-save-package-data.conf 文件：

  • OpenGPGCheck = yes/no

将OpenGPGCheck指令设置为yes（默认设置）将告诉ABRT仅分析和处理由GPG密钥签名的包提供的应用程序中的崩溃，GPG密钥的位置列在/etc/ABRT/GPGu keys文件中。将OpenGPGCheck设置为no将告诉ABRT捕获所有程序中的崩溃。

  • BlackList = nspluginwrapper, valgrind, strace, [more_packages ]

在黑名单指令之后列出的包和二进制文件中的崩溃将不会由ABRT处理。如果您希望ABRT忽略其他包和二进制文件，请在此处列出它们，并用逗号分隔。

  • ProcessUnpackaged = yes/no

这个指令告诉ABRT是否处理不属于任何包的可执行文件中的崩溃。默认设置为 no .

  • BlackListedPaths = /usr/share/doc/*, */example*

ABRT将忽略这些路径中可执行文件的崩溃。

中支持以下配置指令 /etc/abrt/plugins/CCpp.conf 文件：

  • MakeCompatCore = yes/no

这个指令指定ABRT的core-catching钩子是否应该创建一个core文件，如果ABRT不被安装的话也可以这样做。核心文件通常在崩溃程序的当前目录中创建，但前提是 ulimit -c 设置允许。指令设置为 yes 默认情况下。

  • SaveBinaryImage = yes/no

此指令指定ABRT的core catching hook是否应将二进制图像保存到core转储。它在调试已删除的二进制文件中发生的崩溃时非常有用。默认设置为 no .

配置ABRT以检测内核死机

ABRT可以使用 abrt-vmcore 服务，由 abrt-addon-vmcore 包裹。该服务在系统引导时自动启动，并在中搜索核心转储文件 /var/crash/ 目录。如果找到核心转储文件， abrt-vmcore 在中创建问题数据目录 /var/spool/abrt/ 目录并将核心转储文件复制到新创建的问题数据目录。之后 /var/crash/ 目录，服务将停止，直到下一次系统启动。

要配置ABRT以检测内核死机，请执行以下步骤：

  1. 确保 kdump 系统上已启用服务。特别是，为 kdump 内核必须正确设置。您可以使用 system-config-kdump 图形化工具，或通过指定 crashkernel 中的内核选项列表中的参数 /etc/grub2.conf 配置文件。

  2. 安装并启用 abrt-addon-vmcore 使用yum的包：

    yum install abrt-addon-vmcore
systemctl enable abrt-vmcore

    这将安装 abrt-vmcore 提供相应的支持和配置文件。

  3. 重新启动系统以使更改生效。

除非ABRT的配置不同，否则任何检测到的内核死机的问题数据现在都存储在 /var/spool/abrt/ ABRT可以像其他检测到的内核oop一样进一步处理。

桌面会话自动报告

已启用自动报告行为

启用桌面会话自动报告后，ABRT会自动上传 μ报告 一旦发现用户的问题。如果abrt服务器 (faf )知道报告的问题，服务器提供有关问题的附加信息，ABRT通过通知气泡通知用户检测到的问题是已知的。通知气泡提供了显示问题的网页、在ABRT GUI中打开问题或忽略问题的功能。如果问题未知，ABRT会显示一个通知气泡，用户可以像往常一样开始报告过程，也可以忽略问题。

已禁用自动报告行为

禁用自动报告后，ABRT上传 μ报告 对于单击后检测到的问题 “报告”按钮 在通知气泡中。如果abrt服务器不知道检测到的问题，abrt将继续执行报告向导。

事件虽然ABRT通知其他用户的问题，但它从不自动上传这些问题的uReports。另一个用户的问题总是以处理禁用自动报告的问题的方式来处理，这在第2段中描述。

如果网络不可用，ABRT将推迟通知检测到的问题，直到网络再次可用。推迟的问题列表将仅为单用户桌面会话保留。如果在桌面会话的生存期内网络不可用，则延迟的问题可能根本不会得到通知。

上传uReports需要一个可写的问题目录，为了使报告更加自动化，减少混乱，ABRT可能会将问题目录从系统转储位置（通常是 /var/spool/abrt/ 目录）到 $HOME/.cache/abrt/spool/ 目录，而不请求用户这样做的权限。但是，只有当用户没有写入系统转储位置的权限时，ABRT才会移动目录。

启用桌面会话自动报告

桌面自动报告可以通过多种方式启用。最简单的方法就是回答 Yes 在对话中要求 启用自动提交的崩溃报告 点击后出现 “报告”按钮 在通知气泡中。第二种方法是打开 Automatic Bug Reporting Tool 应用程序，打开应用程序菜单并单击以下选项：

ABRT Configuration

并启用选项：

Automatically send uReport

最后但最不方便的方法是手动编辑文件：

$HOME/.config/abrt/settings/abrt-applet.conf

并添加以下行：

AutoreportingEnabled = yes

系统自动报告

ABRT可以配置为提交 μ报告 对于abrt服务器的每个检测到的问题 (faf )一旦他们被发现。服务器提供有关提交的问题的以下信息：

  • 现有错误报告的URL（如果有）（Bugzilla错误）

  • 简短描述文本

可以通过发出以下命令来启用系统自动报告：

abrt-auto-reporting enabled

或通过 Augeas:

augtool set /files/etc/abrt/abrt.conf/AutoreportingEnabled yes

或者在 /etc/abrt/abrt.conf 配置文件：

AutoreportingEnabled yes

启用系统自动报告时，也会启用桌面会话自动报告。

缩短的报告

在自动报告事件完成后报告中断的情况下启用缩短的GUI报告。这意味着报告是在用户单击时完成的 “报告”按钮 在通知气泡上。在那之后，ABRT上传了一个 uReport 描述已处理的问题，显示一个通知气泡，说明问题已报告并完成。

缩短的报告对从GUI开始的报告过程没有影响，因为我们希望高级用户能够轻松地将完整的bug报告提交到Bugzilla中。我们相信所有关心检测到的崩溃和打开的用户 自动错误报告工具 应用程序可以看到他们是高级用户。

Default value: Yes but only if application is running in GNOME desktop

要打开缩短的报告：

Automatic Bug Reporting Tool

转到应用程序菜单并单击：

ABRT Configuration

并启用选项：

Shortened Reporting

或手动编辑文件：

$HOME/.config/abrt/settings/abrt-applet.conf

再加上一行：

ShortenedReporting = yes

自动敏感数据过滤

ABRT保存着 敏感词 在里面 /etc/libreport/forbidden_words.conf 因此，为了更改所有用户的列表，系统管理员必须编辑此文件。中还有每个用户的列表 $HOME/.config/abrt/settings/forbidden_words.conf （默认情况下不存在，因此用户必须创建它）。文件的格式是每行一个字。通配符是 NOT 支持。

禁词有时是其他词的一部分，通常不被视为敏感信息。提供此类假阳性敏感词供用户审核，使得从报表中删除敏感数据的过程变得困难，可能会遗漏真正的敏感数据。因此，ABRT有另一个从未被视为敏感信息的单词列表。该列表包含以下常用词 敏感词 . 全球 忽略的词 保存在文件中：

/etc/libreport/ignored_words.conf

以及每个用户列表：

$HOME/.config/abrt/settings/ignored_words.conf

事件配置

每个事件由相应配置文件中的一个规则结构定义。配置文件通常存储在 /etc/libreport/events.d/ 目录。这些配置文件由主配置文件加载， /etc/libreport/report_event.conf .

这个 /etc/libreport/report_event.conf 文件由include指令和规则组成。规则通常存储在 /etc/libreport/events.d/ 目录。

如果您想修改这个文件，请注意它尊重shell元字符 (* ， $ ， ? ，并解释相对于其位置的相对路径。

每个规则都以一行非空格的前导字符开头，所有以空格字符或制表符开头的后续行都被视为该规则的一部分。每个规则由两部分组成，一个条件部分和一个程序部分。条件部分包含以下形式之一的条件：

VAR=VAL,

VAR!=VAL

VAL~=REGEX

在哪里？

  • VAR 要么是 EVENT 问题数据目录元素的关键字或名称，例如 executable ， package ， hostname ，..。看见 ABRT收集的元素 想要更多。

  • 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"

可能发生的事件并不是固定的。系统管理员可以根据需要添加事件。目前，标准ABRT和libreport安装提供了以下事件名称：

post-create

此事件由自动运行 abrtd 在新创建的问题数据目录上。当 post-create 事件已运行， abrtd 检查 UUID 新问题数据的标识符与 UUID 任何已经存在的问题目录。如果存在这样的问题目录，则删除新的问题数据。看到了吗 重复数据消除 有关重复处理的详细信息。

analyze_name_suffix

在哪里？ name_suffix 是事件名称的可调整部分。此事件用于处理收集的数据。例如 analyze_LocalGDB 运行GNU调试器 (GDB )应用程序的核心转储上的实用程序，并生成崩溃的回溯。

collect_name_suffix

其中nameu后缀是事件名称的可调整部分。此事件用于收集有关问题的其他信息。

report_name_suffix

其中nameu后缀是事件名称的可调整部分。此事件用于报告问题。

有关事件的附加信息（如事件的描述、名称和可以作为环境变量传递给它们的参数类型以及其他属性）存储在 /etc/libreport/events/event_name.xml 文件夹。GUI和CLI都使用这些文件，以使用户界面更友好。除非要修改标准安装，否则不要编辑这些文件。

标准ABRT安装支持的事件

标准ABRT安装目前提供了许多默认的分析、收集和报告事件。其中一些事件可以使用 gnome-abrt GUI应用程序。以下是ABRT标准安装提供的默认分析、收集和报告事件列表：

analyze_VMcore -分析VM核心

跑 GDB （GNU调试器）处理应用程序的问题数据，并生成内核的回溯。定义见 /etc/libreport/events.d/vmcore_event.conf 配置文件。

analyze_LocalGDB -本地GNU调试器

跑 GDB （GNU调试器）并生成崩溃的回溯。定义见 /etc/libreport/events.d/ccpp_event.conf 配置文件。

analyze_RetraceServer -远程生成回溯

上载核心转储到 回溯服务器 用于远程回溯生成。定义见 /etc/libreport/events.d/ccpp_retrace_event.conf 配置文件。

analyze_xsession_errors -Collect.xsession错误

从中保存相关行 ~/.xsession-errors 提交到问题报告。定义见 /etc/libreport/events.d/ccpp_event.conf 配置文件。

report_Logger -记录器

创建问题报告并将其保存到指定的本地文件。定义见 /etc/libreport/events.d/print_event.conf 配置文件。

report_Mailx -邮件

通过发送问题报告 mailx 指定电子邮件地址的实用程序。i它在 /etc/libreport/events.d/mailx_event.conf 配置文件。

report_Uploader -报表上载程序

上传一个tarball (.tar.gz )使用FTP或SCP协议将有问题的数据存档到选定的目标。定义见 /etc/libreport/events.d/uploader_event.conf 配置文件。

report_uReport - μ报告 上传器

上载 μ报告 到 faf 服务器。

report_EmergencyAnalysis — Upload problem directory to faf

将tarball上传到 faf 服务器进行进一步分析。用于标准报告方法失败时报告失败的情况。定义见 /etc/libreport/events.d/emergencyanalysis_event.conf 配置文件。

工作流配置

report gtk和report cli是报告应用程序崩溃和abrtd守护程序捕获的其他问题的工具，或者由使用libreport的其他程序创建的工具。为此，他们调用所谓的 EVENTs . 有两种方法可以指定要执行的事件。可以将其指定为命令行参数（选项 -e EVENT )要报告gtk/report cli，也可以在 工作流文件 位于 /usr/share/libreport/workflows/ . 中定义了将使用哪些工作流文件 工作流配置文件 在里面 /etc/libreport/workflows.d/ .

工作流中使用的每个事件都必须有相应的XML描述文件 /usr/share/libreport/events/ . 这些文件的格式在 report_event.conf(5) 人页。

工作流文件

中的每个XML文件 /usr/share/libreport/workflows/ 必须符合以下DTD：

<!ELEMENT workflow    (name+,description+,priority?,events*)>
<!ELEMENT name        (#PCDATA)>
<!ATTLIST name         xml:lang CDATA #IMPLIED>
<!ELEMENT description (#PCDATA)>
<!ATTLIST description  xml:lang CDATA #IMPLIED>
<!ELEMENT priority =  (#PCDATA)>
<!ELEMENT events =    (event)+>
<!ELEMENT event =     (#PCDATA)>
name

工作流的面向用户的名称。

description

工作流的面向用户的描述。

priority

工作流的优先级。数字越大，用户界面中的位置越明显。如果没有提供，则使用0。该值是有符号整数。

events

工作流中执行的事件列表。

event

要执行的事件的名称。也可以使用通配符 (* )在名称的末尾选择多个具有公共前缀的事件。如果某个事件不适用于问题数据或未定义，则流程将继续处理下一个同级事件。

工作流配置文件

配置文件包含在给定条件下执行哪些工作流的规则。每一条规则都以一行非空格的前导字符开始。每个规则由两部分组成：工作流名称和以下格式的可选条件：

EVENT=<WORKFLOW_NAME> [CONDITION]

后一部分由以下形式之一的条件的空格分隔列表组成：

VAR=VAL,

VAR!=VAL, or

VAL~=REGEX

在哪里？

  • VAR 是有问题的数据目录元素（例如 executable ， package ， hostname 等等——见 ABRT收集的元素 更多信息），

  • VAL 是有问题的数据元素，并且

  • REGEX 是正则表达式。

装载程序

report gtk或report cli查看 /etc/libreport/workflows.d/ 目录并遍历每个配置文件中的所有规则，检查是否满足每个规则的指定条件。

如果只有一个工作流的条件得到满足，则从中加载其规范 /usr/share/libreport/workflows/<WORKFLOW_NAME>.xml 它的每一个事件都被执行。如果有多个工作流符合这些条件，则用户可以选择执行哪一个工作流。

工作流示例

为了说明这个过程，我们提供了一个为mailx创建工作流的示例，即POSIX邮件实用程序。第一步是在中创建工作流配置文件 /etc/libreport/workflows.d/ 内容如下：

EVENT=workflow_mailx analyzer=CCpp

这指示记者寻找一个 workflow_mailx.xml 文件在 /usr/share/libreport/workflow/ 每当分析器是CCpp（崩溃分析器为C和C++）。

在第二步中，我们创建所需的工作流文件， workflow_mailx.xml ，内容如下：

<?xml version="1.0" encoding="UTF-8"?>
<workflow>
    <name>Send the problem data via mailx</name>
    <description>Analyze the problem locally and send information via mailx</description>
    <priority>-99</priority>

    <events>
        <event>report_Mailx</event>
    </events>
</workflow>

它指示报告程序（report gtk或report cli）运行事件 report_Mailx 作为此工作流的唯一步骤。

第三步是创建事件配置文件 report_Mailx.xml 对应于 report_Mailx 来自 workflow_mailx.xml 上述配置文件。该文件的内容如下：

<?xml version="1.0" encoding="UTF-8" ?>
<event>
    <name>Mailx</name>
    <description>Send via email</description>

    <requires-items></requires-items>
    <exclude-items-by-default>count,event_log,reported_to,coredump,vmcore</exclude-items-by-default>
    <exclude-items-always></exclude-items-always>
    <exclude-binary-items>no</exclude-binary-items>
    <include-items-by-default></include-items-by-default>
    <minimal-rating>0</minimal-rating>
    <gui-review-elements>yes</gui-review-elements>

    <options>
        <option type="text" name="Mailx_Subject">
            <label>Subject</label>
            <allow-empty>no</allow-empty>
            <description>Message subject</description>
            <default-value>[abrt] detected a crash</default-value>
        </option>
        <option type="text" name="Mailx_EmailFrom">
            <label>Sender</label>
            <allow-empty>no</allow-empty>
            <description>Sender's email</description>
        </option>
        <option type="text" name="Mailx_EmailTo">
            <label>Recipient</label>
            <allow-empty>no</allow-empty>
            <description>Recipient's email</description>
        </option>
        <option type="bool" name="Mailx_SendBinaryData">
            <label>Send Binary Data</label>
            <description>Send binary files like coredump</description>
            <default-value>no</default-value>
        </option>
    </options>
</event>

调整插件配置

ABRT向不同的目的地报告问题。几乎每个报告目的地都需要一些配置。例如，Bugzilla需要登录名、密码和指向Bugzilla服务实例的URL。一些配置细节可以有默认值（例如Bugzilla的URL），但其他配置细节没有合理的默认值（例如login）。

ABRT允许用户通过文本配置文件提供配置，例如 /etc/libreport/events/report_Bugzilla.conf . 所有文本配置文件都由键/值对组成。

事件文本配置可以存储在以下文件之一中：

  • /etc/libreport/events/somename.conf -对于系统范围配置

  • $XDG_CACHE_HOME/abrt/events/somename.conf -用于用户范围配置 [XDG]

这些文件是在问题目录上运行事件所必需的最少文件。ABRT GUI和CLI工具将从这些文件中读取配置数据，并将其传递给它们运行的事件。

但是，为了使GUI界面更加用户友好，可以在同一目录中的XML文件中提供附加信息，例如 report_Bugzilla.xml . 这些文件可以包含以下信息：

  • 用户友好的事件名称和描述( 布奇拉 ， 向Bugzilla bug tracker报告 ）

  • 问题目录中事件成功所需的项的列表。

  • 默认和强制选择要发送或不发送的项目。

  • GUI是否应提示进行数据审查。

  • 存在哪些配置选项、它们的类型（字符串、布尔值等）、默认值、提示字符串等。这使GUI能够构建适当的配置对话框。

ABRT的GUI将配置选项保存在 gnome-keyring 或 ksecrets 并将它们传递给事件，覆盖文本配置文件中的数据。

通过执行以下命令，可以获取特定事件的一组密钥：

xmllint --xpath "/event/options/option/@name" $EVENT_XML_FILE | sed 's/name="\([^ ]*\)"/\1\n/g'

事件XML定义文件和事件配置文件之间的映射：

事件名称

定义文件

配置文件

布奇拉

report_Bugzilla.xml

report_Bugzilla.conf

记录器

report_Logger.xml

report_Logger.conf

C/C++碰撞分析

analyze_CCpp.xml

analyze_CCpp.conf

本地GNU调试器

analyze_LocalGDB.xml

analyze_LocalGDB.conf

回溯服务器

analyze_RetraceServer.xml

analyze_RetraceServer.conf

分析VM核心

analyze_VMcore.xml

analyze_VMcore.conf

收集GConf配置

collect_GConf.xml

collect_GConf.conf

收集系统范围的vim配置文件

collect_vimrc_system.xml

collect_vimrc_system.conf

收集vim配置文件

collect_vimrc_user.xml

collect_vimrc_user.conf

Collect.xsession错误

collect_xsession_errors.xml

collect_xsession_errors.conf

事后报告

post_report.xml

post_report.conf

Kerneloops.org

report_Kerneloops.xml

report_Kerneloops.conf

邮件

report_Mailx.xml

report_Mailx.conf

报表上载程序

report_Uploader.xml

report_Uploader.conf

uReport公司

report_uReport.xml

report_uReport.conf

默认情况下，如果没有配置任何强制选项，ABRT会抱怨缺少配置。强制选项是未标记为“允许空”的选项。运行以下命令以获取强制选项列表：

xmllint --xpath "/event/options/option[allow-empty!='yes']/@name" $EVENT_XML_FILE \
        | sed 's/name="\([^ ]*\)"/\1\n/g'