systemd-coredump(8)

Legacy handler units, used on kernels that do not support the kernel coredump socket protocol (see "Kernel Requirements" above). The kernel invokes systemd-coredump directly and in privileged mode for each crash; that instance connects to systemd-coredump.socket, which in turn spawns an unprivileged systemd-coredump@.service instance to actually process and save the core dump. Unlike systemd-coredumpd.service, a fresh systemd-coredump@.service instance is started for every core dump, so it always reads the current coredump.conf configuration.

.RE

.SS "Core dumps in Containers/Namespaces"

.PP The systemd-coredump@.service service will automatically attempt to extract a stacktrace from a process as it crashes. For this stacktrace symbols will be resolved based on debug information embedded in the crashing ELF image, or equivalent debug information separately available on the host OS. For processes that crash inside of local containers or other mount namespace-based sandboxes, this auxiliary debug information is typically not available on the host (simply because containers typically run different software versions than the host). systemd-coredump provides two mechanisms to address this:

.PP If both CoredumpReceive= is enabled on the unit of the container the core dump belongs to, and EnterNamespace= is enabled in the coredump.conf configuration file, the former takes precedence.

.SH "CONFIGURATION"

.PP For programs started by systemd, process resource limits can be set by directive LimitCORE=, see systemd.exec(5).

.PP In order to be used by the kernel to handle core dumps, systemd-coredump must be configured in sysctl(8) parameter kernel.core_pattern. The syntax of this parameter is explained in core(5). systemd installs the file /usr/lib/sysctl.d/50-coredump.conf which configures kernel.core_pattern accordingly. This file may be masked or overridden to use a different setting following normal sysctl.d(5) rules. If the sysctl configuration is modified, it must be updated in the kernel before it takes effect, see sysctl(8) and systemd-sysctl(8).

.PP On systems where systemd-coredumpd.service is active (see "Kernel Requirements" and "Units" above), systemd-coredump-register.service writes its own kernel.core_pattern setting to /run/sysctl.d/60-coredump.conf whenever systemd-coredumpd.service is running, and this file takes precedence over /usr/lib/sysctl.d/50-coredump.conf. As a result, masking or overriding 50-coredump.conf alone does not override the default kernel.core_pattern on such systems, since 60-coredump.conf will still take effect. To set a custom kernel.core_pattern of your own on a system where systemd-coredumpd.service is active, stop and disable it:

systemctl disable --now systemd-coredumpd.service

.PP In order to be used in the --backtrace mode, an appropriate backtrace handler must be installed on the sender side. For example, in case of python(1), this means a sys.excepthook must be installed, see systemd-coredump-python[3].

.PP The behavior of systemd-coredump itself is configured through the configuration file /etc/systemd/coredump.conf and corresponding snippets /etc/systemd/coredump.conf.d/*.conf, see coredump.conf(5). When core dumps are processed via systemd-coredump@.service (see "Units" above), a new instance of systemd-coredump is invoked upon receiving every core dump, and changes in these files will take effect the next time a core dump is received. When core dumps are instead processed by the long-running systemd-coredumpd.service, configuration changes require an explicit reload of that service to take effect; see coredump.conf(5) for details.

.PP Resources used by core dump files are restricted in two ways. Parameters like maximum size of acquired core dumps and files can be set in files /etc/systemd/coredump.conf and snippets mentioned above. In addition the storage time of core dump files is restricted by systemd-tmpfiles, corresponding settings are by default in /usr/lib/tmpfiles.d/systemd.conf. The default is to delete core dumps after a few days; see the above file for details.

.SS "Disabling coredump processing"

.PP To disable potentially resource-intensive processing by systemd-coredump, set

Storage=none
ProcessSizeMax=0

in coredump.conf(5).

.SH "INFORMATION ABOUT THE CRASHED PROCESS"

.PP coredumpctl(1) can be used to retrieve saved core dumps independently of their location, to display information, and to process them e.g. by passing to the GNU debugger (gdb).

.PP Data stored in the journal can be also viewed with journalctl(1) as usual (or from any other process, using the sd-journal(3) API). The relevant messages have MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1:

$ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose
...
MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
COREDUMP_PID=552351
COREDUMP_UID=1000
COREDUMP_GID=1000
COREDUMP_SIGNAL_NAME=SIGSEGV
COREDUMP_SIGNAL=11
COREDUMP_CODE=2
COREDUMP_TIMESTAMP=1614342930000000
COREDUMP_COMM=Web Content
COREDUMP_EXE=/usr/lib64/firefox/firefox
COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope
COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser ...
COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-....scope
COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web....552351.....zst
...

.PP The following fields are saved (if known) with the journal entry

.PP COREDUMP_UID=, COREDUMP_PID=, COREDUMP_GID=

fd:/path/to/file
pos:     ...
flags:   ...
...
fd:/path/to/file
pos:     ...
flags:   ...
...

$ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web....552351.....zst
# file: /var/lib/systemd/coredump/core.Web....552351.....zst
user.coredump.pid="552351"
user.coredump.uid="1000"
user.coredump.gid="1000"
user.coredump.signal="11"
user.coredump.timestamp="1614342930000000"
user.coredump.comm="Web Content"
user.coredump.exe="/usr/lib64/firefox/firefox"
...