Jes*_*ess 9 ubuntu coredump crash-dumps
我们有一个部署了启用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文件规范). ..有没有办法做到这一点,或等同的东西？
小智 11
另一种方法是使用Apport来处理崩溃.它将保存核心转储,以及关于崩溃的大量其他有用的上下文.添加以下行~/.config/apport/settings(如果它不存在,则创建它):
[main]
unpackaged=true
现在崩溃将显示为Apport .crash文件/var/crash.你可以打开包装apport-unpack.
一个警告:如果用户离开了"发送错误报告"复选框,Apport仍会尝试将这些崩溃上传到Ubuntu错误跟踪器; 如果您正在使用专有代码等,这可能是一个问题.我正在寻找更多关于此的信息; 似乎/etc/apport/crashdb.conf可以控制崩溃报告的发送位置.
如果它是未打包的二进制文件，apport 仍然会遵守，/proc/sys/kernel/core_uses_pid因此您可以对其进行设置以增加获得正确核心文件的机会。
假定/proc/sys/kernel/core_pattern有对 apport 本身的引用，因此在这种情况下 apport 没有什么可回退的。
/usr/share/apport/apport您可以在脚本中看到内核核心模式通过 apport 调用的代码。
一个明显的替代方案是创建一个新的 Python 脚本来使用，就像那个脚本一样，但对函数进行了修改write_user_coredump，然后通过内核核心模式 sysctl 将其连接起来。