> Hello Matej, > > 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 [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. 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 > 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? 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. > > > 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. _______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
