Core dump
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 systemd-coredump) for further processing. Core dumps may be useful for developers to debug program crashes, however they are practically useless to the average user, and have been largely obsoleted by modern debuggers.
Contents
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.
Using systemd
systemd's default behavior is to generate core dumps for all processes in /var/lib/systemd/coredump
. This behavior can be overridden by creating a configuration snippet in the /etc/systemd/coredump.conf.d/
directory with the following content[1][2]:
/etc/systemd/coredump.conf.d/custom.conf
[Coredump] Storage=none
Then reload systemd's configuration.
# systemctl daemon-reload
This method alone is usually sufficient to disable userspace core dumps, so long as no other programs enable automatic core dumps on the system.
Using ulimit
The maximum core dump size is enforced by ulimit. Setting it to zero disables core dumps entirely. [3]
/etc/security/limits.conf
* hard core 0
Using sysctl
sysctl can be used to modify the fs.suid_dumpable
kernel parameter. This only applies to suid processes. [4]
/etc/sysctl.conf
fs.suid_dumpable = 0
Making a core dump
To generate a core dump of an arbitrary process, first install the gdb package. Then find the PID of the running process, for example with pgrep:
$ pgrep -f firefox
2071 firefox
Attach to the process:
$ gdb -p 2071
Then at the (gdb)
prompt:
(gdb) generate-core-file Saved corefile core.2071 (gdb) quit
Now you have a coredump file called core.2071
.
Where do they go?
The kernel.core_pattern
sysctl decides where automatic core dumps go:
$ cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e
The default set in /usr/lib/sysctl.d/50-coredump.conf
sends all core dumps to journald as part of the system logs.
To retrieve a core dump from the journal, see man coredumpctl
Examining a core dump
Use coredumpctl to find the corresponding dump:
# coredumpctl list
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 coredumpctl(1)
and journalctl(1)
for details). To see details of the core dumps:
# coredumpctl info match
Pay attention to "Signal" row, that helps to identify crash cause. For deeper analysis you can examine the backtrace using gdb:
# coredumpctl gdb match
When gdb is started, use the bt
command to print the backtrace:
(gdb) bt
See also
- american fuzzy lop - An tool for automated tests of the kernel and programs
- Filesystem fuzzing - LWN article about testing filesystems for bugs