|
NAME | SYNOPSIS | DESCRIPTION | CONFIGURATION | USAGE | SEE ALSO | NOTES | COLOPHON |
|
|
|
SYSTEMD-COREDUMP(8) systemd-coredump SYSTEMD-COREDUMP(8)
systemd-coredump, systemd-coredump.socket, systemd-
coredump@.service - Acquire, save and process core dumps
/usr/lib/systemd/systemd-coredump
/usr/lib/systemd/systemd-coredump --backtrace
systemd-coredump@.service
systemd-coredump.socket
systemd-coredump@.service is a system service that can acquire
core dumps from the kernel and handle them in various ways. The
systemd-coredump executable does the actual work. It is invoked
twice: once as the handler by the kernel, and the second time in
the systemd-coredump@.service to actually write the data to the
journal.
When the kernel invokes systemd-coredump to handle a core dump,
it runs in privileged mode, and will connect to the socket
created by the systemd-coredump.socket unit, which in turn will
spawn an unprivileged systemd-coredump@.service instance to
process the core dump. Hence systemd-coredump.socket and
systemd-coredump@.service are helper units which do the actual
processing of core dumps and are subject to normal service
management.
Core dumps can be written to the journal or saved as a file. Once
saved they can be retrieved for further processing, for example
in gdb(1).
By default, systemd-coredump will log the core dump including a
backtrace if possible to the journal and store the core dump
itself in an external file in /var/lib/systemd/coredump.
The behavior of a specific program upon reception of a signal is
governed by a few factors which are described in detail in
core(5). In particular, the core dump will only be processed when
the related resource limits are sufficient.
It is also possible to invoke systemd-coredump with --backtrace
option. In this case, systemd-coredump expects a journal entry in
the journal Journal Export Format[1] on standard input. The entry
should contain a MESSAGE= field and any additional metadata
fields the caller deems reasonable. systemd-coredump will append
additional metadata fields in the same way it does for core dumps
received from the kernel. In this mode, no core dump is stored in
the journal.
For programs started by systemd, process resource limits can be
set by directive LimitCORE=, see systemd.exec(5).
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).
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[2].
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). A new instance of systemd-coredump is invoked
upon receiving every core dump. Therefore, changes in these files
will take effect the next time a core dump is received.
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.
Disabling coredump processing
To disable potentially resource-intensive processing by
systemd-coredump, set
Storage=none
ProcessSizeMax=0
in coredump.conf(5).
Data stored in the journal can be viewed with journalctl(1) as
usual. coredumpctl(1) can be used to retrieve saved core dumps
independent of their location, to display information and to
process them e.g. by passing to the GNU debugger (gdb).
coredump.conf(5), coredumpctl(1), systemd-journald.service(8),
systemd-tmpfiles(8), core(5), sysctl.d(5),
systemd-sysctl.service(8).
1. Journal Export Format
https://www.freedesktop.org/wiki/Software/systemd/export
2. systemd-coredump-python
https://github.com/keszybz/systemd-coredump-python
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
⟨http://www.freedesktop.org/wiki/Software/systemd/#bugreports⟩.
This page was obtained from the project's upstream Git repository
⟨https://github.com/systemd/systemd.git⟩ on 2020-12-18. (At that
time, the date of the most recent commit that was found in the
repository was 2020-12-18.) If you discover 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 to
man-pages@man7.org
systemd 247 SYSTEMD-COREDUMP(8)
Pages that refer to this page: coredumpctl(1), core(5), coredump.conf(5), systemd.directives(7), systemd.index(7), systemd-journald.service(8)
|
HTML rendering created 2020-12-21 by Michael Kerrisk, author of The Linux Programming Interface, maintainer of the Linux man-pages project. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|