Course contentsShow
← Linux
Lesson 1544 of 1,81913. Containerization Primitives and NamespacesFree lesson

Core Dump Analysis for Containers

Configure kernel core dump patterns to include the context of the originating namespace.

In this lesson, you will learn how to configure the kernel core dump pattern to ensure that diagnostic artifacts retain the necessary namespace context for containerized debugging.

The Challenge of Shared Dumps

When a process crashes, the Linux kernel generates a core dump file. By default, the kernel writes these to a global location defined in /proc/sys/kernel/core_pattern. In a containerized environment, a simple filename pattern like core.%p is insufficient. Because PIDs are namespaced, multiple containers can have processes with the same PID, leading to collisions where core files overwrite each other. Furthermore, without namespace identifiers, you lose the ability to map a core dump back to the specific container or PID namespace that hosted the crashed process.

Configuring Namespace-Aware Patterns

To distinguish between namespaces, the kernel allows us to include specific modifiers in the core_pattern. Specifically, using the %n (for PID namespace) or %i (for the PID in the current namespace) tokens allows us to disambiguate dumps.

To ensure your system captures context-aware core dumps, you should update the core_pattern to include namespace identifiers:

# Set the core pattern to include the PID, the host PID, and the namespace ID
echo "/tmp/cores/core.%e.%p.ns%n" > /proc/sys/kernel/core_pattern

In this configuration:

  • %e: The executable filename.
  • %p: The PID of the crashed process.
  • %n: The ID of the PID namespace (inode number).

By including %n, the kernel embeds the PID namespace's unique inode number into the filename. When you inspect the /tmp/cores/ directory, you can identify which dumps belong to the same container environment by grouping them by this namespace identifier.

Operational Considerations

When debugging, remember that the directory specified in core_pattern must be writable by the crashed process’s user, or you must use a pipe-based pattern (starting with |) to delegate the dump to a handler script. A custom handler can then extract the process's nsenter context or metadata from /proc/<pid>/ns/ before the process state disappears. This ensures that even after the container crashes or is restarted, the preserved dump provides the exact environmental context needed for post-mortem analysis.

Key Takeaway: By appending the namespace inode identifier (%n) to the kernel's core_pattern, you prevent cross-container file collisions and retain the critical metadata required to map a core dump back to its originating PID namespace.