2013-01-07 24 views
5

我们有一个启用了apport的Ubuntu服务器,如图所示。如何更改非打包应用程序崩溃的apport默认行为?

~$ 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文件规范)...有没有这样做的方法,或者有什么相同的东西?

+0

可能存在[未生成核心转储文件]的副本(http://stackoverflow.com/questions/7732983/core-dump-file-is-not-generated) – conradkdotcom

回答

0

如果它是一个未打包的二进制文件,apport仍然会遵守/proc/sys/kernel/core_uses_pid,所以你可以设置它来增加获得正确核心文件的机会。

/proc/sys/kernel/core_pattern被认为是对apport本身的引用,所以在这种情况下,没有什么东西可以适用。

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

一个明显的选择是创建一个新的Python脚本来使用,就像那样,但在write_user_coredump函数中进行了修改,然后通过内核内核模式sysctl挂钩。

1

另一种选择是使用Apport来处理你的崩溃。它将保存核心转储以及大量关于崩溃的其他有用上下文。添加以下行来~/.config/apport/settings(创建它,如果它不存在):

[main] 
unpackaged=true 

现在崩溃将出现Apport会.crash在/var/crash文件。你可以用apport-unpack解开它们。

一个警告:如果用户离开'发送错误报告'复选框被选中,似乎Apport仍然尝试将这些崩溃上载到Ubuntu bug跟踪器;这可能是一个问题,如果你正在处理专有代码等。我正在寻找更多的信息;看起来/etc/apport/crashdb.conf可以控制崩溃报告发送的位置。

相关问题