How to Use the coredumpctl Command in Linux to Retrieve, Inspect, and Debug Application Crashes

When a process terminates abnormally due to a segmentation fault, illegal instruction, or unhandled signal, the Linux kernel can generate a memory snapshot known as a core dump. Historically, managing core dump files across multi-user servers was cumbersome, often filling disk partitions or scattering uncompressed binaries across working directories. Modern Linux distributions utilize systemd-coredump to automatically capture, compress, and catalogue process crashes. The companion utility, coredumpctl, provides administrators and developers with a centralized command-line interface to inspect crash logs, view stack traces, and launch debuggers directly.

Verifying systemd-coredump Service Status

Before querying crash dumps, verify that systemd-coredump is actively capturing kernel core signals. Run:

systemctl status systemd-coredump.socket

The socket should be listed as active (listening). Additionally, verify that the kernel core pattern directs crashes to the systemd handler by inspecting /proc/sys/kernel/core_pattern:

cat /proc/sys/kernel/core_pattern

The output typically references |/usr/lib/systemd/systemd-coredump ..., confirming that abnormal program terminations are piped into the systemd journal archive.

Listing Captured Core Dumps with coredumpctl list

To inspect all recorded crashes catalogued on the system, execute:

coredumpctl list

This displays a tabular summary sorted chronologically:

• TIME: Timestamp of the process crash.
• PID: Process ID at the time of the fault.
• UID & GID: User and group IDs under which the process was running.
• SIG: Signal that terminated the process (e.g., SIGSEGV for segmentation fault, SIGABRT for abort).
• COREFILE: Storage status of the memory dump (e.g., present, truncated, or none).
• EXE: Absolute filesystem path to the executable that crashed.

To filter for crashes from a specific executable or PID:

coredumpctl list /usr/bin/nginx
coredumpctl list 49201

Viewing Granular Crash Information and Stack Traces

To inspect forensic details of a crash without loading an external debugger, use the info subcommand:

coredumpctl info /usr/bin/nginx

If multiple crashes exist for the executable, coredumpctl presents the most recent event. The detailed report includes:

• Hardware architecture, kernel version, and cgroup slicing.
• Signal number, faulting memory address, and registers dump.
• An embedded stack backtrace highlighting the source code function, instruction offset, and dynamic shared library where the crash occurred.

Launching GDB Directly into the Crash Context

To step through the crash interactively, inspect variable states, and evaluate call frames, coredumpctl can launch the GNU Debugger (GDB) directly using the stored dump and original binary:

coredumpctl debug /usr/bin/my-app

Alternatively, target a specific crash using its PID:

coredumpctl debug 58210

GDB loads the executable symbols, mounts the core dump from the systemd archive, and displays the exact breakpoint prompt ((gdb)) ready for commands such as bt full or info registers.

Extracting and Exporting Core Dumps for Remote Analysis

In production environments, developers rarely run GDB on live servers due to security policies or missing debugging symbols. To export a raw core dump file to your local directory for external triage:

coredumpctl dump /usr/bin/my-app --output=/tmp/crash_dump.core

This decompresses the archive and writes a standard ELF core file that can be transferred via SCP to a development workstation containing full debugging symbols (dbgsym packages).

Managing Disk Space and Core Dump Retention Policies

Unchecked crash dumps can consume substantial NVMe storage. Configure retention limits and disk quotas in /etc/systemd/coredump.conf:

[Coredump]
Storage=external
Compress=yes
ProcessSizeMax=2G
ExternalSizeMax=5G
MaxUse=10%

Key directives:

• Storage=external: Stores core dumps as compressed files in /var/lib/systemd/coredump/.
• Compress=yes: Compresses core images using Zstandard (zstd) or LZ4.
• MaxUse=10%: Ensures coredumps do not exceed 10% of total filesystem capacity.

Core Command Reference Table

Command Syntax	Diagnostic Purpose
coredumpctl list	Shows tabular summary of all captured application crashes.
coredumpctl info [Target]	Displays detailed metadata, registers, and stack backtrace.
coredumpctl debug [Target]	Launches GDB preloaded with the executable and core dump.
coredumpctl dump [Target] -o [File]	Extracts raw uncompressed core file for offline investigation.