常见问题

ABRT在哪里存储崩溃故障？

ABRT将其问题目录存储在 /var/spool/abrt 目录。请注意，目录本身是可读的 root 仅在默认情况下。

ABRT能处理什么类型的崩溃故障？

见 支持的编程语言和软件项目 .

当ABRT无法捕捉到我的应用程序崩溃时该怎么办？

  • 确保以下服务正在运行：

    • abrtd

    • abrt-ccpp

    $ systemctl status abrtd abrt-ccpp

  • 如果其中一个没有运行，可以使用以下命令重新启动这两个程序：

    $ sudo systemctl restart abrtd abrt-ccpp

  • 如果上述方法无效，请咨询 journactl 或 /var/log/messages 错误日志。

  • 默认情况下，ABRT不会处理由第三方（未打包的）软件产生的崩溃，这样才能正常工作 How to enable handling of unpackaged software .

如何处理未打包的软件

  • 编辑 /etc/abrt/abrt-action-save-package-data.conf 和改变 ProcessUnpackaged = no 到 ProcessUnpackaged = yes

    # sed -i 's/ProcessUnpackaged = no/ProcessUnpackaged = yes/' /etc/abrt/abrt-action-save-package-data.conf

如何处理非GPG签名的软件

  • 编辑 /etc/abrt/abrt-action-save-package-data.conf 和改变 OpenGPGCheck = yes 到 OpenGPGCheck = no

    # sed -i 's/OpenGPGCheck = yes/OpenGPGCheck = no/' /etc/abrt/abrt-action-save-package-data.conf

如何列出由ABRT处理的崩溃？

  • 使用任一GUI应用程序： $ gnome-abrt

  • 或命令行工具： $ abrt-cli list

    见 使用 了解更多详细信息。

什么是报告？

  • μ报告 (microreport )是一个表示问题的JSON对象：二进制崩溃、内核操作、SELinux AVC拒绝等。这些报告被设计成小的、完全匿名的，允许我们使用它们进行自动报告。

    见 μ报告 有关详细信息，请参见第页。

什么是被污染的内核？为什么我的内核被污染了？

Linux内核维护一个 污染状态 它指示正在运行的内核是否发生了可能导致内核错误的事情。

常见原因包括：

  • 已加载专有内核模块（P标志）

  • 发生上一个内核错误（kerneloops）（D标志）。

  • 上一个内核警告 (GW 标志）。

  • 两种情况 D 旗与 GW 标志表示内核数据结构可能已损坏。因此，当前误差不一定是真正的误差，它可能是前一个误差的随机结果。

  • 为了摆脱受污染的内核，您需要重新启动计算机或停止加载专有模块。

  • ABRT尊重这些标志，并且不允许报告一个或多个标志是否有效，因为当内核被污染时，内核开发人员通常无法修复问题。

污点标志的完整列表：

P - Proprietary module has been loaded.
F - Module has been forcibly loaded.
S - SMP with CPUs not designed for SMP.
R - User forced a module unload.
M - System experienced a machine check exception.
B - System has hit bad_page.
U - Userspace-defined naughtiness.
D - Kernel has oopsed before
A - ACPI table overridden.
W - Taint on warning.
C - modules from drivers/staging are loaded.
I - Working around severe firmware bug.
O - Out-of-tree module has been loaded.

资料来源：http://git.kernel.org/？p=linux/kernel/git/torvalds/linux.git文件；a=blob；f=kernel/panic.c

如何创建私有bugzilla票证？

ABRT可以创建具有受限访问权限的报告，这意味着对报告的访问权限仅限于一组受信任的人。请注意，限制不同的错误追踪器，即使你标记为限制它仍然可以泄漏给公众，所以如果你不确定，那么不要报告任何东西！

要创建私有bugzilla票证，必须指定要限制访问的组列表。棘手的是，它必须是bugzilla数据库中组的内部id。为了减轻痛苦，以下是受支持bugzillas的私有组ID列表：

Bugzilla服务器

组名

要在设置中使用的组ID

http://bugzilla.redhat.com

Fedora Contrib（Fedora Contrib成员可访问的错误）

fedora_contrib_private

http://bugzilla.redhat.com

私有组（Bug只能由维护人员访问）

私有的

如何启用屏幕播放？

要在abrt中启用屏幕广播，您必须安装fros包，其中包含与您的桌面环境匹配的插件。目前只有2个插件可用： fros-gnome 和 fros-recordmydesktop . Gnome插件只适用于GNOME3， recordmydesktop 应该与大多数其他桌面环境一起工作。要安装插件，请运行以下命令之一（取决于桌面环境）：：

yum install fros-gnome
yum install fros-recordmydesktop

为什么ABRT分析收集受污染的内核oopses？

ABRT分析收集受污染的oop，因为每个收到的oop都被转发到http://oops.kernel.org/人们希望看到 每一个 哦，还有 不仅是纯洁的 那些。

为什么我的回溯无法使用？

不可用的回溯通常是由损坏的核心转储、缺少调试信息或使用不受支持的编码技术（即GNOME3中的JavaScript）引起的。

这些原因导致生成的回溯对开发人员的信息价值很低，因为函数名被替换为 '??' 字符串，它是不可用函数名的占位符。为了提供有价值的崩溃报告，ABRT不会让您为这种回溯创建Bugzilla bug。

您可以使用ABRT通过 Email reporter ，但这是你自己的责任。

如何启用setuid二进制文件转储

默认情况下，内核不会转储设置的用户ID或其他受保护/污染的二进制文件。要改变这种行为，你需要改变 fs.suid_dumpable 内核变量。

要读取值，请使用：

sysctl fs.suid_dumpable

要更改值，请使用：

sysctl fs.suid_dumpable=0

可能的值是：

  1. (default )-传统行为。任何已更改权限级别或仅执行的进程都不会被转储。

  2. (debug )-所有进程尽可能转储核心。核心转储由当前用户拥有，不应用任何安全性。这仅适用于系统调试情况。Ptrace未选中。这是不安全的，因为它允许常规用户检查特权进程的内存内容。

  3. (suidsafe )-任何通常不会转储的二进制文件（请参见上面的“0”）都只能由root读取。这允许用户删除核心转储文件，但不读取它。出于安全原因，此模式下的核心转储不会覆盖彼此或其他文件。当管理员试图在正常环境中调试问题时，此模式是合适的。

    此外，由于Linux 3.6，/proc/sys/kernel/coreu模式必须是绝对路径名或管道命令，如core（5）中所述。如果coreu模式不遵循这些规则，则会将警告写入内核日志，并且不会生成核心转储。

资料来源：http://man7.org/linux/man-pages/man5/proc.5.html