> > Nope, everything landing through the helper on the host is what happens > whenever you have a core pattern that starts with a "|". Similarly, any > pattern which isn't just a file name (like "core") but is instead an > absolute path, will be treated as an absolute path on the host, not in > the container where the crash occurred.
Aha. I suppose this is where my misunderstanding arose from. I assumed that the kernel was container aware in this context, since it seemed to handle relative file name paths rather well. Didn't realise this worked just because of relative paths. Firstly, thank you for the detailed explanation. I highly appreciate your patience in taking the time for providing a detailed answer. I see this complicates things, and the problem with my initial view on part of the argument. Now, having said that, systemd-coredump in the Red Hat land just leave the dumps on the host. I don't see why apport shouldn't do the same. And having read further on this now, https://github.com/abrt/abrt/wiki/Analysing-core-dump-files-of-containerized-process -- this seems to be the RHEL way of doing this. I still strongly believe swallowing dumps is a bad idea. The co-relation of the container process has to be manual, but swallowing dump because it's "inconvenient" to map to the correct process doesn't seem like the right thing to do. I'm also curious about the last few lines stating abrt devs are working on automating some of the discovery, as per the end of the document. I also fail to see why not to let apport handle just the reporting side of things, and adopt into systemd-coredump for the core dump handler, as it does it rather well, and being a part of the systemd suite with much lower overhead, and without the dependency that apport pulls along. I do not see the value in Ubuntu maintaining another core dump handler, while the OSS community arguably is unifying around a better one.
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
