Matej Marusak [2017-09-06 15:15 -0000]:
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 , and useful , 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.
does. Or it depends on your understanding of 'support':)
We do not know what package does the crash comes from - firstly because nobody implemented
that but secondly it seems that ppl who create images do not really care about packages
anymore - just copy what you need into image.
We know container typ, container id, image and docker_inspect. Also cgroups, environ,
limits, maps, mountinfo, namespaces, pwd...
And as I look into that, we do not know OS, but know image, so it is lookable.
The concept of ABRT/Apport collecting "standard" operating system crash
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?
ABRT supports both types of
containers. But yes, we aim for docker 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.
This is great question. Right now we
are finishing new feature and prepared FAF image. The idea is that if you run huge amount
of containers (such as OpenShift) you deploy FAF as well and set ABRT to report into your
own FAF. This also supports reporting crashes without packages.
>  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
>  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.