The following options are understood:
Print a short help text and exit.
Print a short version string and exit.
Do not print column headers.
Do not pipe output into a pager.
Show information of a single core dump only, instead of listing
all known core dumps.
Only print entries which are since the specified date.
Only print entries which are until the specified date.
Reverse output so that the newest entries are displayed first.
-F FIELD, --field=FIELD
Print all possible data values the specified field takes in
matching core dump entries of the journal.
-o FILE, --output=FILE
Write the core to FILE.
-D DIR, --directory=DIR
Use the journal files in the specified DIR.
Suppresses info messages about lack of access to journal files
and possible in-flight coredumps.
The following commands are understood:
List core dumps captured in the journal matching specified
characteristics. If no command is specified, this is the implied
The output is designed to be human readable and contains list
contains a table with the following columns:
The timestamp of the crash, as reported by the kernel.
The identifier of the process that crashed.
The user and group identifiers of the process that crashed.
The signal that caused the process to crash, when applicable.
Information whether the coredump was stored, and whether it
is still accessible: "none" means the the core was not
stored, "-" means that it was not available (for example
because the process was not terminated by a signal),
"present" means that the core file is accessible by the
current user, "journal" means that the core was stored in the
"journal", "truncated" is the same as one of the previous
two, but the core was too large and was not stored in its
entirety, "error" means that the core file cannot be
accessed, most likely because of insufficient permissions,
and "missing" means that the core was stored in a file, but
this file has since been removed.
The full path to the executable. For backtraces of scripts
this is the name of the interpreter.
It's worth noting that different restrictions apply to data saved
in the journal and core dump files saved in
/var/lib/systemd/coredump, see overview in systemd-coredump(8).
Thus it may very well happen that a particular core dump is still
listed in the journal while its corresponding core dump file has
already been removed.
Show detailed information about core dumps captured in the
Extract the last core dump matching specified characteristics.
The core dump will be written on standard output, unless an
output file is specified with --output=.
Invoke the GNU debugger on the last core dump matching specified
A match can be:
Process ID of the process that dumped core. An integer.
Name of the executable (matches COREDUMP_COMM=). Must not contain
Path to the executable (matches COREDUMP_EXE=). Must contain at
least one slash.
General journalctl predicate (see journalctl(1)). Must contain an
equals sign ("=").
Example 1. List all the core dumps of a program named foo
# coredumpctl list foo
Example 2. Invoke gdb on the last core dump
# coredumpctl gdb
Example 3. Show information about a process that dumped core,matching by its PID 6654
# coredumpctl info 6654
Example 4. Extract the last core dump of /usr/bin/bar to a file namedbar.coredump
# coredumpctl -o bar.coredump dump /usr/bin/bar
This page is part of the systemd (systemd system and service manager)
project. Information about the project can be found at
⟨http://www.freedesktop.org/wiki/Software/systemd⟩. If you have a bug
report for this manual page, see
page was obtained from the project's upstream Git repository
⟨https://github.com/systemd/systemd.git⟩ on 2017-03-13. If you dis‐
cover any rendering problems in this HTML version of the page, or you
believe there is a better or more up-to-date source for the page, or
you have corrections or improvements to the information in this
COLOPHON (which is not part of the original manual page), send a mail
systemd 233 COREDUMPCTL(1)