Question

如图所示，我们已经部署了启用了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文件）规范）...有没有办法做到这一点，或等同的东西？

Answer 1

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

[main]
unpackaged=true

现在崩溃将在/var/crash中显示为Apport .crash文件。您可以使用apport-unpack解压缩它们。

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

Answer 2

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

假设/proc/sys/kernel/core_pattern引用了apport本身，因此在这种情况下，apport没有任何回复。

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

一个明显的替代方案是创建一个新的Python脚本，就像那个，但在write_user_coredump函数中修改，然后通过内核核心模式sysctl挂钩。

如何更改非打包应用程序崩溃的apport默认行为？

2 个答案: