|
Top-level
 …in systemd-nspawn: they have a proper init system as PID 1, as well as service management, so that they can actually reasonably process coredumps inside in parallel to whatever else they are supposed to be doing. Of course, containers in the Docker sense are not like that: they typically run in some weird mixture of "i am an independent system" and "i am part of another system", and the payload is run as PID 1 without any further service management available. Bummer! 3 comments
In many situations this new feature should be "good enough" to extract stack traces from containers, but of course it's not going to be able to fully address the fact that containers and host typically are built with different compiler/debugging settings, i.e. that the coredump processing and the coredump payload originate from different vendors with all the differences in generation this brings. And of course, the security angle deserves attention: we are processing untrusted data… …here that comes from a differently trusted environment (the container payload) on the host. While we try to lock things down via sandboxing knobs, this nevertheless is not riskless. Because of that it's an opt-in thing, and it would be wise to enable this only if you sufficiently trust your container payloads. |
Gregory's Server
With v257 there's now a knob to address this situation too. systemd-coredump can now be configured (opt-in!) so that it will try to process coredumps of containers *on the host*. If you set EnterNamespace=yes in coredump.conf it will acquire access to the container's mount tree, mount it within its own private mount namespace to some special location, and then run coredump processing on that – while being part of the host runtime in almost all ways.