A core dump is a file containing a process's address space (memory) when the process terminates unexpectedly. Core dumps may be produced on-demand (such as by a debugger), or automatically upon termination. Core dumps are triggered by the kernel in response to program crashes, and may be passed to a helper program (such as ) for further processing. A core dump is not typically used by an average user, but developers could use it as a post-mortem snapshot of the program's state at the time of the crash, especially if the fault is hard to reliably reproduce.
Disabling automatic core dumps
Users may wish to disable automatic core dumps for a number of reasons:
- Performance: generating core dumps for memory-heavy processes can waste system resources and delay the cleanup of memory.
- Disk space: core dumps of memory-heavy processes may consume disk space equal to, if not greater, than the process's memory footprint if not compressed.
- Security: core dumps, although typically readable only by root, may contain sensitive data (such as passwords or cryptographic keys), which are written to disk following a crash.
sysctl can be used to set the
kernel.core_pattern to nothing to disable core dump handling. Create this file
To apply the setting immediately, use
# sysctl -p /etc/sysctl.d/50-coredump.conf
systemd's default behavior is defined in
/usr/lib/sysctl.d/50-coredump.conf, which sets
kernel.core_pattern to call
systemd-coredump. It generates core dumps for all processes in
systemd-coredump behavior can be overridden by creating a configuration snippet in the
/etc/systemd/coredump.conf.d/ directory with the following content (See , ):
[Coredump] Storage=none ProcessSizeMax=0
[Coredump]section name, otherwise this option will be ignored.
Then reload the systemd manager configuration with daemon-reload.
Using PAM limits
* hard core 0
Command-line shells such as bash or zsh provide a builtin ulimit command which can be used to report or set resource limits of the shell and the processes started by the shell. See or for details.
To disable core dumps in the current shell:
$ ulimit -c 0
If the system is setup to pipe coredumps into a program such as systemd-coredump using
kernel.core_pattern, Linux ignores the ulimit setting and only the
dumpable can be used to disable coredump processing for selected processes.
Making a core dump
To generate a core dump of an arbitrary process, first install the package. Then find the PID of the running process, for example with pgrep:
$ pgrep -f firefox
Attach to the process:
$ gdb -p 2071
Then at the
(gdb) generate-core-file Saved corefile core.2071 (gdb) quit
Now you have a coredump file called
Where do they go?
kernel.core_pattern sysctl decides where automatic core dumps go. By default, core dumps are sent to systemd-coredump which can be configured in
/etc/systemd/coredump.conf. By default, all core dumps are stored in
/var/lib/systemd/coredump (due to
Storage=external) and they are compressed with
zstd (due to
Compress=yes). Additionally, various size limits for the storage can be configured.
kernel.core_patternis set in
/usr/lib/sysctl.d/50-coredump.conf. This file may be masked or overridden to use a different setting following normal rules.
To retrieve a core dump from the journal, see.
Managing the core dump files
Use coredumpctl to find the corresponding dump. Note that regular users can run coredumpctl without special privileges to manage core dumps of their processes.
# coredumpctl list
Cleanup of core dump files
The core dump files stored in
/var/lib/systemd/coredump/ will be automatically cleaned by
systemd-tmpfiles --clean, which is triggered daily with
systemd-tmpfiles-clean.timer. Core dumps are configured to persist for at least 3 days, see
Analyzing a core dump
First, you need to uniquely identify the relevant dump. This is possible by specifying a
PID, name of the executable, path to the executable or a journalctl predicate (see and for details). To see details of the core dumps:
# coredumpctl info match
Pay attention to "Signal" row, that helps to identify crash cause. For the analysis one usually examine the backtrace using a debugger (by default):
# coredumpctl debug match
When gdb is started, use the
bt command to print the backtrace:
In many cases, the output will contain question marks as placeholders for missing debugging symbols. See Debugging/Getting traces for how to obtain them.