设计

守护进程

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>/ 这可能对调试有用- mapslimitscgroupstatus . 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_bactraceuuid 我们正在处理的问题目录中的项。

如果有一个 core_backtrace 时,它会迭代所有其他转储目录,并计算与其核心回溯(如果有的话)的相似度。如果它们中的一个相似到足以被认为是重复的,则事件处理将停止,并且仅 notify-dup 事件被激发。

如果有 uuid 项目(没有核心回溯),简单比较 uuid 哈希用于重复检测。

ABRT收集的元素

常用元素:

财产

意义

例子

executable

导致问题的组件的可执行路径。服务器用于确定 componentpackage 数据。

'/usr/bin/time'

type

问题类型M,参见 支持的问题类型 .

'Python'

component

导致此问题的组件。

'time'

hostname

受影响计算机的主机名。

'fiasco'

os_release

操作系统释放字符串。

'Fedora release 17 (Beefy Miracle)'

uid

用户ID

1000

username

用户名

'jeff'

architecture

机器体系结构字符串

'x86_64'

kernel

内核版本字符串

'3.6.6-1.fc17.x86_64'

package

包字符串

'time-1.7-40.fc17.x86_64'

time

发生时间(unixtime)

datetime.datetime(2012, 12, 2, 16, 18, 41)

count

此问题发生的次数

1

pkg_name

程序包名称

'time'

pkg_epoch

包装时代

0

pkg_version

程序包版本

'1.7'

pkg_release

软件包发布

'40.fc17'

pkg_arch

软件包体系结构

'x86_64'

uuid

作为回溯的前三帧的散列计算的唯一问题标识符

'c55e3deb95d46553fdbefb1bc1d020e89a762fb7'

取决于问题类型的要素:

财产

意义

例子

适用

abrt_version

ABRT版本字符串

'2.0.18.84.g211c'

崩溃被 ABRT 捕获

cgroup

崩溃进程的cgroup(control group)信息

'9:perf_event:/\n8:blkio:/\n...'

C/C++

core_backtrace

无私有数据的机器可读回溯

C/C++,Python,Ruby,Kerneloops

backtrace

原始回溯或回溯过程产生的回溯

C/C++(重描后),Python,Ruby,XORG,Kerneloops

dso_list

崩溃时加载的动态库列表

C/C++,Python

exploitable

可能的崩溃原因和可利用评级

C/C++

maps

副本 /proc/<pid>/maps 问题可执行文件

C/C++

cmdline

副本 /proc/<pid>/cmdline 文件

'/usr/bin/gtk-builder-convert'

C/C++,Python,Ruby,Kerneloops

coredump

撞击过程中的堆芯倾倒

C/C++

environ

进程的运行时环境

C/C++,Python

open_fds

崩溃时打开的文件描述符列表

C/C++

pid

进程ID

'42'

C/C++,Python,露比

proc_pid_status

副本 /proc/<pid>/status 文件

C/C++

limits

副本 /proc/<pid>/limits 文件

C/C++

var_log_messages

部分 /var/log/messages 包含崩溃信息的文件

C/C++

suspend_stats

副本 /sys/kernel/debug/suspend_stats

内核操作

reported_to

如果已经报告了问题,则此项包含报告问题的服务的URL

报告的问题

event_log

ABRT事件日志

报告的问题

dmesg

副本 dmesg

内核操作