如何更改非打包应用程序崩溃的apport默认行为？
我们有一个部署了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文件规范)……有什么方法可以做到这一点，或者其他类似的方法吗？
回答 2
Stack Overflow用户
发布于 2017-01-10 04:16:31
另一种选择是使用Apport来处理崩溃。它将保存核心转储，以及大量有关崩溃的其他有用上下文。将以下行添加到~/.config/apport/settings (如果它不存在，则创建它)：
[main]
unpackaged=true现在，崩溃将在/var/crash中显示为支持.crash文件。你可以用apport-unpack解压它们。
一个警告:如果用户选中了“发送错误报告”复选框，Apport似乎仍然会尝试将这些崩溃上传到Ubuntu bug跟踪器；如果你正在处理专有代码等，这可能是一个问题。我正在寻找有关这方面的更多信息；似乎/ etc /apport/crashdb.conf可能控制崩溃报告的发送位置。
Stack Overflow用户
发布于 2015-12-07 23:42:11
如果它是一个未打包的二进制文件，apport仍然遵循/proc/sys/kernel/core_uses_pid，所以你可以设置它来增加你获得正确核心文件的机会。
假设/proc/sys/kernel/core_pattern有一个对apport本身的引用，所以在这种情况下apport没有什么可以后退的。
您可以在/usr/share/apport/apport脚本中看到代码，该脚本由使用apport的内核核心模式调用。
一种显而易见的替代方法是创建一个新的Python脚本来使用，就像这个脚本一样，但是在write_user_coredump函数中进行修改，然后通过内核核心模式sysctl将其连接起来。
https://stackoverflow.com/questions/14204961
复制相似问题
腾讯云开发者
