Reputation: 437
We have an Ubuntu server deployed with apport enabled as shown.
~$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
Unfortunately apport's behaviour in dealing with non-packaged application crashes is not entirely to our liking. apport is producing "core" files (assuming ulimit -c is set appropriately) in the working directory in these scenarios. For example, from the apport logs,
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)
Frustratingly, once a core file is there it will not be overwritten. So for example if we're testing an app and forgot to clear an old core file from the working directory, then the app crashes during test, we won't see a new core file. Even if it were overwritten, this might not be ideal either as we then lose the old core.
Ideally what we'd like is the ability to tell apport, via an argument for example, that for non-packaged application case, generate a core file with a file name formatted according to a specified pattern (as per the core_pattern file specification) ... is there any way of doing this, or something equivalent?
Upvotes: 26
Views: 13659
Reputation: 450
Another alternative is to use Apport to handle your crashes. It will save the core dump, along with a ton of other useful context about the crash. Add the following lines to ~/.config/apport/settings
(create it if it doesn't exist):
[main]
unpackaged=true
Now crashes will appear as Apport .crash files in /var/crash
. You can unpack them with apport-unpack
.
One caveat: it appears that Apport still tries to upload these crashes to the Ubuntu bug tracker if the user leaves the 'Send error report' checkbox checked; this may be a problem if you are working on proprietary code, etc. I'm looking for more info on this; it seems that /etc/apport/crashdb.conf may control where the crash reports get sent.
Upvotes: 35
Reputation: 809
If it's an unpackaged binary, apport will still abide by /proc/sys/kernel/core_uses_pid
so you can set that to increase your chances of getting the right core file.
The /proc/sys/kernel/core_pattern
is assumed to have a reference to apport itself, so there's nothing for apport to fall back to in such a case.
You can see the code in the /usr/share/apport/apport
script that is invoked by the kernel core pattern with apport.
An obvious alternative would be to create a new Python script to use, just like that one, but with modifications in the write_user_coredump
function, and then hook that up through the kernel core pattern sysctl.
Upvotes: 0