X-Git-Url: http://git.ipfire.org/?a=blobdiff_plain;f=man%2Fsystemd-coredump.xml;h=1ab7e598a7c46583145372829da01014c35c624b;hb=fb282d4e256a79b19d3299999024e8fafd2ab0a0;hp=f1598461ef618b95535d96efda62370e9f37402a;hpb=76fba3ca608931e0f5a43e01039297d6e38be2c2;p=thirdparty%2Fsystemd.git diff --git a/man/systemd-coredump.xml b/man/systemd-coredump.xml index f1598461ef6..1ab7e598a7c 100644 --- a/man/systemd-coredump.xml +++ b/man/systemd-coredump.xml @@ -1,25 +1,7 @@ - - - - + + + @@ -27,15 +9,6 @@ systemd-coredump systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - @@ -45,50 +18,120 @@ systemd-coredump - Log and store core dumps + systemd-coredump.socket + systemd-coredump@.service + Acquire, save and process core dumps /usr/lib/systemd/systemd-coredump + /usr/lib/systemd/systemd-coredump + systemd-coredump@.service + systemd-coredump.socket Description + 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 + gdb1. + + + 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. - systemd-coredump can be used as a helper - binary by the kernel when a user space program receives a fatal - signal and dumps core. For it to be used in this capacity, it must - be specified by the - kernel.core_pattern sysctl8 - setting. Systemd installs - /usr/lib/sysctl.d/50-coredump.conf which - configures kernel.core_pattern to invoke - systemd-coredump. This file may be masked or - overridden to use a different setting following normal - sysctl.d5 rules. - - The behavior of a specific program upon reception of a - signal is governed by a few factors which are described in detail - in core5. - In particular, the coredump will only be processed when the - related resource limits are high enough. For programs started by - systemd, those may be set using - LimitCore= (see - systemd.exec5). + The behavior of a specific program upon reception of a signal is governed by a few + factors which are described in detail in + core5. + In particular, the core dump will only be processed when the related resource limits are sufficient. - systemd-coredump will log the coredump - including a backtrace if possible, and store the core (contents of - process' memory contents) in an external file on disk in - /var/lib/systemd/coredump, or directly in - the journal. This behavior may be modified using - coredump.conf5. + It is also possible to invoke systemd-coredump with + option. In this case, systemd-coredump expects + a journal entry in the journal + Journal Export Format + 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. + - Apart from the + + Configuration + For programs started by systemd process resource limits can be set by directive + LimitCore=, see + systemd.exec5. + + + In order to be used by the kernel to handle core dumps, + systemd-coredump must be configured in + sysctl8 + parameter kernel.core_pattern. The syntax of this parameter is explained in + core5. + 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.d5 + rules. If the sysctl configuration is modified, it must be updated in the kernel before it + takes effect, see + sysctl8 + and + systemd-sysctl8. + + + In order to by used in the mode, an appropriate backtrace + handler must be installed on the sender side. For example, in case of + python1, this + means a sys.excepthook must installed, see + systemd-coredump-python. + + + 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.conf5. 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.conf5. + + + + + + Usage + Data stored in the journal can be viewed with journalctl1 - log viewer, + as usual. coredumpctl1 - may be used to list and extract coredumps. + 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). @@ -97,6 +140,7 @@ coredump.conf5, coredumpctl1, systemd-journald.service8, + systemd-tmpfiles8, core5, sysctl.d5, systemd-sysctl.service8.