Hello Matej,
Matej Marusak [2017-09-06 15:15 -0000]:
The ABRT team had an idea - ABRT can catch problems from containers
and ABRT displays problems in Cockpit.
Does ABRT actually support that already? I'm asking because a colleague and me
worked on that feature in Apport a few years ago. It's actually quite tricky to
get it right, robust [1], and useful [2], i. e. letting the crash handler on
the host deal with a container process crash isn't going to be able to collect
much information. A simple core dump is of course still useful for manual
investigation, it's just rather laborious to get useful details out of it.
The concept of ABRT/Apport collecting "standard" operating system crash reports
works rather well with full system containers (LXC or nspawn style) where the
guest OS can run ABRT and the data collection, but my gut feeling is that you
rather aim towards docker application containers here?
In the docker case, what do you intend to do with the ABRT reports? They most
certainly shouldn't be sent to the Fedora crash database, they belong to the
author of the affected docker container - but hub.docker.io doesn't have any
kind of crash database or even a bug tracker.
Thanks,
Martin
[1] We first attempted to let the host's apport create the core dump and
report, but this leads to a lot of corner cases such as
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1318,
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1324, or
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1325.
[2] In order to collect any information in addition to the core dump, such as
symbols, /proc/pid/maps files, OS and package versions, package-specific hooks
to provide additional information, etc., assembling the crash report needs the
file system and permissions from *inside* the container. Also, you don't even
know what kind of operating system/which packages are running in the container.