How to change apport default behaviour for non-packaged application crashes?
Asked Answered
P

2

24

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?

Patrizius answered 7/1, 2013 at 22:11 Comment(1)
Possible duplicate of Core dump file is not generatedChristianson
U
33

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.

Undulation answered 9/1, 2017 at 20:16 Comment(3)
Information on how to enable/disable crash reporting: wiki.ubuntu.com/Apport#How_to_enable_apportVeronique
Actually it is responsibility of whoopsie utitily to send crash reports. How to confige it, see here askubuntu.com/questions/135540/…Wicopy
Another issue is that if you run the program multiple times apport just decides to stop dumping with log message "this executable already crashed 2 times, ignoring". I don't see how to disable that with configs:askubuntu.com/questions/1349047/… To prevent upload, the best option I can see is to set "Never" under Settings > Privacy > Diagnostics > Send error reports to Canonical.Dawkins
P
0

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.

Prut answered 7/12, 2015 at 15:42 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.