Using coredumpctl (with examples)

Introduction

The coredumpctl command is a useful tool provided by systemd to retrieve and process saved core dumps and their associated metadata. It allows system administrators and developers to analyze and debug issues by examining core dumps generated during program crashes.

In this article, we will explore different use cases of the coredumpctl command, along with code examples for each use case. We will cover listing all captured core dumps, filtering core dumps by program, retrieving information about specific core dumps, invoking a debugger with a core dump, and extracting core dumps to a file.

Use Case 1: Listing all captured core dumps

The list subcommand of coredumpctl is used to display a list of all captured core dumps. This can be useful to get an overview of available core dumps on the system.

Code:

coredumpctl list

Motivation:

By listing all captured core dumps, system administrators and developers can quickly identify the number and types of crashes that have occurred on the system. This information can assist in identifying recurring issues or tracking the stability of a particular program or system component.

Explanation:

The list subcommand without any additional arguments will list all captured core dumps on the system. The command retrieves metadata about each core dump, including the program name, PID, time of the crash, and path to the core dump file.

Example Output:

TIME                            PID   UID   GID   SIG  COREFILE  EXE
Sun 2021-08-15 14:37:46 CEST   123   1000  1000  11   /tmp/coredump   /usr/bin/myprogram
Mon 2021-08-16 08:12:54 CEST   456   1000  1000  6    /var/crash/core   /usr/bin/otherprogram
...

Use Case 2: Listing captured core dumps for a program

The list subcommand of coredumpctl can also be used to filter core dumps by a specific program. This is helpful when you want to focus on crashes related to a particular program.

Code:

coredumpctl list program

Motivation:

By listing captured core dumps for a specific program, developers can quickly locate crashes related to that program and analyze them in detail. This allows for targeted troubleshooting and investigation, saving time and effort.

Explanation:

The list subcommand followed by the name of the program will filter the core dumps and display only those associated with that program. The program name can be an absolute path to the executable or just the executable name.

Example Output:

TIME                            PID   UID   GID   SIG  COREFILE  EXE
Sun 2021-08-15 14:37:46 CEST   123   1000  1000  11   /tmp/coredump   /usr/bin/myprogram
Tue 2021-08-17 09:30:12 CEST   789   1000  1000  6    /var/crash/core   myprogram
Wed 2021-08-18 16:45:21 CEST   987   1000  1000  8    /home/user/core   /usr/local/bin/myprogram
...

Use Case 3: Retrieving information about core dumps

The info subcommand of coredumpctl is used to retrieve detailed information about specific core dumps matching a given process ID (PID).

Code:

coredumpctl info PID

Motivation:

When a specific issue needs to be investigated, retrieving information about a particular core dump can provide valuable insights into the crash. This information can include the program’s execution path, user and group IDs, as well as the signal number and the path to the core dump file.

Explanation:

The info subcommand followed by the PID of the process provides detailed information about the core dump associated with that PID. The PID can be obtained from the output of the list subcommand.

Example Output:

           PID: 123
           UID: 1000
           GID: 1000
        Signal: 11
     Timestamp: Sun 2021-08-15 14:37:46 CEST
     Executable: /usr/bin/myprogram
    Description: Program terminated with signal SEGV (Address boundary error)
     Core File: /tmp/coredump

Use Case 4: Invoking debugger with a core dump

The debug subcommand of coredumpctl is used to invoke a debugger with the last core dump of a program.

Code:

coredumpctl debug program

Motivation:

By invoking a debugger with a core dump, developers can analyze the program state at the time of the crash. This allows for in-depth inspection of variables, stack traces, and execution paths, aiding in the identification and resolution of bugs.

Explanation:

The debug subcommand followed by the name of the program will launch a debugger (gdb by default) with the last captured core dump of that program. The program name can be an absolute path to the executable or just the executable name.

Example Output:

gdb /usr/bin/myprogram /tmp/coredump
GNU gdb (GDB) 9.1
...
<debugger output>
gdb>

Use Case 5: Extracting core dump to a file

The --output option of coredumpctl allows you to extract the last core dump of a program to a file.

Code:

coredumpctl --output=path/to/file dump program

Motivation:

Extracting a core dump to a file allows for offline analysis and archiving. It provides a way to share core dumps with developers or load them into a debugger at a later time.

Explanation:

The --output option followed by the path to the output file, the dump subcommand, and the name of the program will extract the last core dump of that program to the specified file. The program name can be an absolute path to the executable or just the executable name.

Example Output:

No output is displayed when extracting a core dump to a file. The core dump is saved to the specified file path.

Conclusion

In this article, we explored different use cases of the coredumpctl command provided by systemd. We covered listing all captured core dumps, filtering core dumps by program, retrieving information about specific core dumps, invoking a debugger with a core dump, and extracting core dumps to a file.

By leveraging the capabilities of coredumpctl, system administrators and developers can efficiently analyze and debug crashes, leading to more robust and stable software systems.