-<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<!--
- This file is part of systemd.
-
- Copyright 2014 Zbigniew Jędrzejewski-Szmek
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-
- systemd is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public License
- along with systemd; If not, see <http://www.gnu.org/licenses/>.
--->
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="systemd-coredump" conditional='ENABLE_COREDUMP'
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>systemd-coredump</title>
<productname>systemd</productname>
-
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>Lennart</firstname>
- <surname>Poettering</surname>
- <email>lennart@poettering.net</email>
- </author>
- </authorgroup>
</refentryinfo>
<refmeta>
<refname>systemd-coredump</refname>
<refname>systemd-coredump.socket</refname>
<refname>systemd-coredump@.service</refname>
- <refpurpose>Log and store core dumps</refpurpose>
+ <refpurpose>Acquire, save and process core dumps</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para><filename>/usr/lib/systemd/systemd-coredump</filename></para>
+ <para><filename>/usr/lib/systemd/systemd-coredump</filename> <option>--backtrace</option></para>
<para><filename>systemd-coredump@.service</filename></para>
<para><filename>systemd-coredump.socket</filename></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
+ <para><filename>systemd-coredump@.service</filename> is a system service that can acquire core
+ dumps from the kernel and handle them in various ways. The <command>systemd-coredump</command>
+ executable does the actual work. It is invoked twice: once as the handler by the kernel, and the
+ second time in the <filename>systemd-coredump@.service</filename> to actually write the data to
+ the journal.</para>
+
+ <para>When the kernel invokes <command>systemd-coredump</command> to handle a core dump, it runs
+ in privileged mode, and will connect to the socket created by the
+ <filename>systemd-coredump.socket</filename> unit, which in turn will spawn an unprivileged
+ <filename>systemd-coredump@.service</filename> instance to process the core dump. Hence
+ <filename>systemd-coredump.socket</filename> and <filename>systemd-coredump@.service</filename>
+ are helper units which do the actual processing of core dumps and are subject to normal service
+ management.</para>
+
+ <para>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
+ <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+ </para>
+
+ <para>By default, <command>systemd-coredump</command> will log the core dump including a backtrace
+ if possible to the journal and store the core dump itself in an external file in
+ <filename>/var/lib/systemd/coredump</filename>.</para>
- <para><command>systemd-coredump</command> 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
- <varname>kernel.core_pattern</varname> <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- setting. The syntax of this setting is explained in
+ <para>The behavior of a specific program upon reception of a signal is governed by a few
+ factors which are described in detail in
<citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- Systemd installs <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> which configures
- <varname>kernel.core_pattern</varname> to invoke <command>systemd-coredump</command>.
- This file may be masked or overridden to use a different setting following normal
- <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- rules.</para>
-
- <para>The behavior of a specific program upon reception of a
- signal is governed by a few factors which are described in detail
- in <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- In particular, the coredump will only be processed when the
- related resource limits are high enough. For programs started by
- <command>systemd</command>, those may be set using
- <varname>LimitCore=</varname> (see
- <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+ In particular, the core dump will only be processed when the related resource limits are sufficient.
</para>
- <para>The behaviour of <command>systemd-coredump</command> is configured through
- <filename>/etc/systemd/coredump.conf</filename> and other configuration files. See
- <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for details. By default, <command>systemd-coredump</command> 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 <filename>/var/lib/systemd/coredump</filename>.</para>
-
- <para>When the kernel invokes <command>systemd-coredump</command> to handle a coredump,
- it will connect to the socket created by the <filename>systemd-coredump.socket</filename>
- unit, which in turn will spawn a <filename>systemd-coredump@.service</filename> instance
- to process the coredump. Hence <filename>systemd-coredump.socket</filename>
- and <filename>systemd-coredump@.service</filename> are helper units which do the actual
- processing of coredumps and are subject to normal service management.</para>
-
- <para>The log entry and a backtrace are stored in the journal, and can be viewed with
- <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
- <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
- may be used to list and extract coredumps or load them in
- <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+ <para>It is also possible to invoke <command>systemd-coredump</command> with
+ <option>--backtrace</option> option. In this case, <command>systemd-coredump</command> expects
+ a journal entry in the journal
+ <ulink url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal Export Format</ulink>
+ on standard input. The entry should contain a <varname>MESSAGE=</varname> field and any additional
+ metadata fields the caller deems reasonable. <command>systemd-coredump</command> 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.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Configuration</title>
+ <para>For programs started by <command>systemd</command> process resource limits can be set by directive
+ <varname>LimitCore=</varname>, see
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
- <para>The coredump helper is invoked anew each time. Therefore, any configuration
- changes will take effect on the invocation of <command>systemd-coredump</command>.
- If the sysctl configuration is modified, it must be updated in the kernel before
- it takes effect, see
- <citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ <para>In order to be used by the kernel to handle core dumps,
+ <command>systemd-coredump</command> must be configured in
+ <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ parameter <varname>kernel.core_pattern</varname>. The syntax of this parameter is explained in
+ <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ systemd installs the file <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> which configures
+ <varname>kernel.core_pattern</varname> accordingly. This file may be masked or overridden to use a different
+ setting following normal
+ <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ rules. If the sysctl configuration is modified, it must be updated in the kernel before it
+ takes effect, see
+ <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
and
- <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+ <citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+ </para>
+
+ <para>In order to by used in the <option>--backtrace</option> mode, an appropriate backtrace
+ handler must be installed on the sender side. For example, in case of
+ <citerefentry project='die-net'><refentrytitle>python</refentrytitle><manvolnum>1</manvolnum></citerefentry>, this
+ means a <varname>sys.excepthook</varname> must installed, see
+ <ulink url="https://github.com/keszybz/systemd-coredump-python">systemd-coredump-python</ulink>.
</para>
+
+ <para>The behavior of <command>systemd-coredump</command> itself is configured through the configuration file
+ <filename>/etc/systemd/coredump.conf</filename> and corresponding snippets
+ <filename>/etc/systemd/coredump.conf.d/*.conf</filename>, see
+ <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. A new
+ instance of <command>systemd-coredump</command> is invoked upon receiving every core dump. Therefore, changes
+ in these files will take effect the next time a core dump is received.</para>
+
+ <para>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 <filename>/etc/systemd/coredump.conf</filename> and snippets mentioned
+ above. In addition the storage time of core dump files is restricted by <command>systemd-tmpfiles</command>,
+ corresponding settings are by default in <filename>/usr/lib/tmpfiles.d/systemd.conf</filename>.</para>
+
+ <refsect2>
+ <title>Disabling coredump processing</title>
+
+ <para>To disable potentially resource-intensive processing by <command>systemd-coredump</command>,
+ set <programlisting>Storage=none
+ProcessSizeMax=0</programlisting> in
+ <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ </para>
+ </refsect2>
+ </refsect1>
+
+ <refsect1>
+ <title>Usage</title>
+ <para>Data stored in the journal can be viewed with
+ <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ as usual.
+ <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ 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).</para>
</refsect1>
<refsect1>
<citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
projects / thirdparty / systemd.git / blobdiff