Where Do Linux Crash Dumps Go?
systemd coredump storage, config and the coredumpctl workflow for reading crash dumps.
Last updated
With systemd-coredump active, crashed processes land compressed in /var/lib/systemd/coredump as core.*.zst files with metadata in extended attributes. Reading other users' dumps needs root, and tmpfiles cleans old ones after a few days.
The daily workflow is coredumpctl: list, info, dump to a file, or debug straight into gdb for a backtrace. Behavior tunes via /etc/systemd/coredump.conf (Storage, size caps) and the kernel core_pattern sysctl that pipes cores to the helper. Journal entries and dump files expire independently, so either side can outlive the other.
Where Linux stores this, by platform
/var/lib/systemd/coredump/
Compressed core.*.zst dumps (root needed for other users' files; tmpfiles expiry). Config in /etc/systemd/coredump.conf plus conf.d (Storage=, ProcessSizeMax=). Activation via kernel.core_pattern sysctl. Read with coredumpctl list/info/dump/debug.
Frequently asked questions
How do I get a backtrace from a crashed program?
Run coredumpctl debug <PID> to open the dump in gdb, then type bt. Use coredumpctl dump <PID> -o file first if you want to keep the dump past tmpfiles expiry.
coredumpctl lists a dump but the file is gone. Why?
Journal entries and dump files expire on separate schedules. The listing survived while tmpfiles already removed the data, or vice versa. Dump to a file promptly for anything you need to keep.
Notice an outdated path? Let us know.