17

如图所示，我们部署了一个启用了 apport 的 Ubuntu 服务器。

~$ cat /proc/sys/kernel/core_pattern 
|/usr/share/apport/apport %p %s %c

不幸的是，apport 在处理非打包应用程序崩溃时的行为并不完全符合我们的喜好。在这些场景中，apport 正在工作目录中生成“核心”文件（假设 ulimit -c 已正确设置）。例如，从 apport 日志中，

ERROR: apport (pid 10117) Tue Jan  8 08:56:25 2013: executable: /home/jess/a.out (command line "./a.out")
ERROR: apport (pid 10117) Tue Jan  8 08:56:25 2013: executable does not belong to a package, ignoring
ERROR: apport (pid 10117) Tue Jan  8 08:56:25 2013: writing core dump to /home/jess/core (limit: 18889465931478580853760)

令人沮丧的是，一旦有核心文件，它就不会被覆盖。因此，例如，如果我们正在测试一个应用程序并且忘记从工作目录中清除旧的核心文件，那么应用程序在测试期间崩溃，我们将看不到新的核心文件。即使它被覆盖，这也可能不是理想的，因为我们会失去旧的核心。

理想情况下，我们希望能够通过参数告诉 apport，例如，对于未打包的应用程序案例，生成一个具有根据指定模式格式化的文件名的核心文件（根据 core_pattern 文件规范）。 ..有什么办法可以做到这一点，或类似的东西吗？

4

2 回答 2

21

另一种选择是使用 Appport 来处理您的崩溃。它将保存核心转储以及有关崩溃的大量其他有用上下文。将以下行添加到~/.config/apport/settings（如果不存在则创建它）：

[main]
unpackaged=true

现在崩溃将显示为 Appor 中的 .crash 文件/var/crash。您可以使用apport-unpack.

一个警告：如果用户选中“发送错误报告”复选框，Appor 似乎仍会尝试将这些崩溃上传到 Ubuntu 错误跟踪器；如果您正在处理专有代码等，这可能是一个问题。我正在寻找有关此的更多信息；似乎 /etc/apport/crashdb.conf 可以控制崩溃报告的发送位置。

于 2017-01-09T20:16:31.323 回答
0

如果它是未打包的二进制文件，apport 仍将遵守，/proc/sys/kernel/core_uses_pid因此您可以设置它以增加获得正确核心文件的机会。

假定引用了 apport 本身，因此在这种/proc/sys/kernel/core_pattern情况下没有什么可以让 apport 回退。

您可以看到/usr/share/apport/apport内核核心模式使用 apport 调用的脚本中的代码。

一个明显的替代方法是创建一个新的 Python 脚本来使用，就像那个脚本一样，但对write_user_coredump函数进行修改，然后通过内核核心模式 sysctl 将其连接起来。

于 2015-12-07T15:42:11.493 回答