设计
守护进程
abrtd 是监视应用程序崩溃的守护进程。当崩溃发生时，它会收集问题数据（核心文件、应用程序的命令行等），并根据崩溃的应用程序的配置和类型采取措施。
By default it uses inotify interface [3] to monitor the dump location
(/var/spool/abrt/) for new directories created by C/C++ hook and a 套接字应用程序接口
(/var/run/abrt/abrt.socket) used by other hooks like Python 钩.
使用套接字而不是直接文件系统访问的原因是安全性。当Python脚本抛出未处理的异常时， Python 钩 捕获它，作为损坏的Python应用程序的一部分运行。应用程序以某些SELinux权限运行，例如，它不能执行其他程序，也不能在中创建文件 /var/spool/abrt 或任何其他需要正确填写问题目录的内容。将这些特权添加到每个应用程序会削弱安全性。Python应用程序最合适的解决方案是打开一个socket，其中 abrtd 正在侦听，将所有相关数据写入该套接字，然后关闭它。 abrtd 处理其余的进程。
C/C++钩子
当C/C++应用程序崩溃内核使用时 core_pattern 来处理崩溃故障。Abrt用管道覆盖默认的coreu模式 abrt-hook-ccpp 将核心转储存储在abrt的转储位置并通知守护进程新的崩溃的可执行文件。它还存储来自 /proc/<PID>/ 这可能对调试有用- maps ， limits ， cgroup ， status . Linux内核的文档中描述了这些文件的格式和含义 [1].
启用C/C++钩子使用：
systemctl enable --now abrt-ccpp
core_pattern
用于指定核心转储文件名模板的变量。如果图案的第一个字符是 | ，内核将把模式的其余部分视为要运行的命令。核心转储将写入该程序的标准输入，而不是文件。
默认情况下， /proc/sys/kernel/core_pattern 包含 core 字符串和内核生成 core.* 当前目录中的文件。
Abrt的C/C++钩子用以下方法来重写：
|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
从而导致内核调用 abrt-hook-ccpp . 详细的描述可以在Linux内核的文档中找到 [2].
调试信息
为了能够从核心转储文件获得功能齐全的GDB回溯，debuginfo数据必须在本地文件系统上可用。这些数据通常以可安装包的形式提供，但是ABRT需要允许非特权用户分析核心转储文件，并将获得的回溯报告给bug跟踪工具。因此，ABRT维护自己的debuginfo目录 /var/cache/abrt-di 所有用户都可以通过 /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache 命令行实用程序。
在检测到新的核心转储文件时，ABRT生成一个构建id列表 (XXYYY..YYY )使用 eu-unstrip -n --core=coredump . 当用户决定报告核心转储文件时，ABRT-debuginfo工具将遍历该列表并记住那些生成文件的构建id XX/YYY..YYY.debug 存在于系统目录中 (/usr/lib/debug/.build-id 或 /usr/lib/.build-id )或者在ABRT debuginfo目录中。最后，在中查找提供调试文件的包 *debug* 存储库，下载并解压缩到ABRT debuginfo目录。
Python 钩
这个 python3-abrt-addon 包为python3应用程序提供了一个异常处理程序。
Python解释器自动导入 abrt.pth 文件安装在 /usr/lib64/python3.7/site-packages/ . 此文件依次导入 abrt_exception_handler.py 它覆盖了Python的默认值 sys.excepthook 使用自定义处理程序将未处理的异常转发到 abrtd 通过其 套接字应用程序接口 .
通过传递 -S Python解释器的选项：
python -S file.py
Oops观察器
观察程序检测到内核oopse abrt-dump-journal-oops ，通常此进程作为守护进程运行并监视systemd日志。当内核oops日志出现时，watcher提取它们并创建problem dir，这将由Kerneloops类型的post create事件处理程序进一步处理。
Xorg观察者
观察程序检测到Xorg崩溃 abrt-dump-journal-xorg . 机制与oops watcher中的机制相同，系统日志被监视，Xorg崩溃在发生时被提取出来。此外，xorg观察器可以配置为搜索下一个xorg崩溃，配置文件位于 /etc/abrt/plugins/xorg.conf .
事件
问题生命周期是由ABRT中的事件驱动的。例如：
Event 1 -创建了问题数据目录。
Event 2 -分析问题数据。
Event 3 -Bugzilla报告了一个问题。
当检测到问题并存储其定义数据时，通过在问题的数据目录上运行事件来处理问题。有关事件配置操作，请参阅 事件配置 .
标准ABRT安装目前支持几个默认事件，可以在问题报告过程中选择和使用这些事件。参考 标准ABRT安装支持的事件 查看这些事件的列表。
ABRT仅自动运行以下三个事件：
post-create在问题目录创建之后运行
notify在处理链完成后运行，以通知用户新问题
notify-dup类似
notify重复问题。看到了吗 重复数据消除 .
重复数据消除
当ABRT捕捉到新的崩溃时，它会将其与存储的其他问题进行比较，以避免存储重复的崩溃。
它首先检查是否有 core_bactrace 或 uuid 我们正在处理的问题目录中的项。
如果有一个 core_backtrace 时，它会迭代所有其他转储目录，并计算与其核心回溯(如果有的话)的相似度。如果它们中的一个相似到足以被认为是重复的，则事件处理将停止，并且仅 notify-dup 事件被激发。
如果有 uuid 项目（没有核心回溯），简单比较 uuid 哈希用于重复检测。
ABRT收集的元素
常用元素：
财产 |
意义 |
例子 |
|---|---|---|
|
导致问题的组件的可执行路径。服务器用于确定 |
|
|
问题类型M，参见 支持的问题类型 . |
|
|
导致此问题的组件。 |
|
|
受影响计算机的主机名。 |
|
|
操作系统释放字符串。 |
|
|
用户ID |
|
|
用户名 |
|
|
机器体系结构字符串 |
|
|
内核版本字符串 |
|
|
包字符串 |
|
|
发生时间（unixtime） |
|
|
此问题发生的次数 |
|
|
程序包名称 |
|
|
包装时代 |
|
|
程序包版本 |
|
|
软件包发布 |
|
|
软件包体系结构 |
|
|
作为回溯的前三帧的散列计算的唯一问题标识符 |
|
取决于问题类型的要素：
财产 |
意义 |
例子 |
适用 |
|---|---|---|---|
|
ABRT版本字符串 |
|
崩溃被 ABRT 捕获 |
|
崩溃进程的cgroup（control group）信息 |
|
C/C++ |
|
无私有数据的机器可读回溯 |
C/C++，Python，Ruby，Kerneloops |
|
|
原始回溯或回溯过程产生的回溯 |
C/C++（重描后），Python，Ruby，XORG，Kerneloops |
|
|
崩溃时加载的动态库列表 |
C/C++，Python |
|
|
可能的崩溃原因和可利用评级 |
C/C++ |
|
|
副本 |
C/C++ |
|
|
副本 |
|
C/C++，Python，Ruby，Kerneloops |
|
撞击过程中的堆芯倾倒 |
C/C++ |
|
|
进程的运行时环境 |
C/C++，Python |
|
|
崩溃时打开的文件描述符列表 |
C/C++ |
|
|
进程ID |
|
C/C++，Python，露比 |
|
副本 |
C/C++ |
|
|
副本 |
C/C++ |
|
|
部分 |
C/C++ |
|
|
副本 |
内核操作 |
|
|
如果已经报告了问题，则此项包含报告问题的服务的URL |
报告的问题 |
|
|
ABRT事件日志 |
报告的问题 |
|
|
副本 |
内核操作 |
支持的问题类型
支持的值 type 元素：
CCppjavaKerneloopsselinuxPythonPython3Rubyxorg
脚注