1
1
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-27 03:21:32 +03:00
systemd-stable/man/coredumpctl.xml

343 lines
11 KiB
XML
Raw Normal View History

<?xml version='1.0'?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
SPDX-License-Identifier: LGPL-2.1+
This file is part of systemd.
Copyright 2012 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/>.
-->
<refentry id="coredumpctl" conditional='ENABLE_COREDUMP'
2015-02-04 05:14:13 +03:00
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>coredumpctl</title>
<productname>systemd</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Zbigniew</firstname>
<surname>Jędrzejewski-Szmek</surname>
<email>zbyszek@in.waw.pl</email>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>coredumpctl</refentrytitle>
<manvolnum>1</manvolnum>
</refmeta>
<refnamediv>
<refname>coredumpctl</refname>
2016-05-16 12:56:04 +03:00
<refpurpose>Retrieve and process saved core dumps and metadata</refpurpose>
2015-02-04 05:14:13 +03:00
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>coredumpctl</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
<arg choice="req">COMMAND</arg>
<arg choice="opt" rep="repeat">PID|COMM|EXE|MATCH</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
2016-05-16 12:56:04 +03:00
<para><command>coredumpctl</command> is a tool that can be used to retrieve and process core
dumps and metadata which were saved by
<citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
2015-02-04 05:14:13 +03:00
</refsect1>
<refsect1>
<title>Options</title>
<para>The following options are understood:</para>
<variablelist>
2016-05-16 12:56:04 +03:00
<xi:include href="standard-options.xml" xpointer="help" />
<xi:include href="standard-options.xml" xpointer="version" />
2015-02-04 05:14:13 +03:00
<varlistentry>
<term><option>--no-legend</option></term>
2016-05-16 12:56:04 +03:00
<listitem><para>Do not print column headers.</para></listitem>
2015-02-04 05:14:13 +03:00
</varlistentry>
2016-05-16 12:56:04 +03:00
<xi:include href="standard-options.xml" xpointer="no-pager" />
2015-02-04 05:14:13 +03:00
<varlistentry>
<term><option>-1</option></term>
2016-05-16 12:56:04 +03:00
<listitem><para>Show information of a single core dump only, instead of listing
all known core dumps.</para></listitem>
2015-02-04 05:14:13 +03:00
</varlistentry>
<varlistentry>
<term><option>-S</option></term>
<term><option>--since</option></term>
<listitem><para>Only print entries which are since the specified date.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-U</option></term>
<term><option>--until</option></term>
<listitem><para>Only print entries which are until the specified date.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-r</option></term>
<term><option>--reverse</option></term>
<listitem><para>Reverse output so that the newest entries are displayed first.
</para></listitem>
</varlistentry>
2015-02-04 05:14:13 +03:00
<varlistentry>
2015-08-25 21:04:55 +03:00
<term><option>-F</option> <replaceable>FIELD</replaceable></term>
<term><option>--field=</option><replaceable>FIELD</replaceable></term>
2015-02-04 05:14:13 +03:00
<listitem><para>Print all possible data values the specified
2016-05-16 12:56:04 +03:00
field takes in matching core dump entries of the
2015-02-04 05:14:13 +03:00
journal.</para></listitem>
</varlistentry>
<varlistentry>
2015-08-25 21:04:55 +03:00
<term><option>-o</option> <replaceable>FILE</replaceable></term>
<term><option>--output=</option><replaceable>FILE</replaceable></term>
2015-02-04 05:14:13 +03:00
<listitem><para>Write the core to <option>FILE</option>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-D</option> <replaceable>DIR</replaceable></term>
<term><option>--directory=</option><replaceable>DIR</replaceable></term>
<listitem><para>Use the journal files in the specified <option>DIR</option>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-q</option></term>
<term><option>--quiet</option></term>
<listitem><para>Suppresses informational messages about lack
of access to journal files and possible in-flight coredumps.
</para></listitem>
</varlistentry>
2015-02-04 05:14:13 +03:00
</variablelist>
2016-05-16 12:56:04 +03:00
</refsect1>
<refsect1>
<title>Commands</title>
2015-02-04 05:14:13 +03:00
<para>The following commands are understood:</para>
<variablelist>
<varlistentry>
<term><command>list</command></term>
2016-05-16 12:56:04 +03:00
<listitem><para>List core dumps captured in the journal
2015-02-04 05:14:13 +03:00
matching specified characteristics. If no command is
2016-05-16 12:56:04 +03:00
specified, this is the implied default.</para>
<para>The output is designed to be human readable and contains list contains
a table with the following columns:</para>
<variablelist>
<varlistentry>
<term>TIME</term>
<listitem><para>The timestamp of the crash, as reported by the kernel.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>PID</term>
<listitem><para>The identifier of the process that crashed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>UID</term>
<term>GID</term>
<listitem><para>The user and group identifiers of the process that crashed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SIGNAL</term>
<listitem><para>The signal that caused the process to crash, when applicable.
</para></listitem>
</varlistentry>
<varlistentry>
<term>COREFILE</term>
<listitem><para>Information whether the coredump was stored, and whether
2017-08-04 00:36:21 +03:00
it is still accessible: <literal>none</literal> means the core was
not stored, <literal>-</literal> means that it was not available (for
example because the process was not terminated by a signal),
<literal>present</literal> means that the core file is accessible by the
current user, <literal>journal</literal> means that the core was stored
in the <literal>journal</literal>, <literal>truncated</literal> is the
same as one of the previous two, but the core was too large and was not
stored in its entirety, <literal>error</literal> means that the core file
cannot be accessed, most likely because of insufficient permissions, and
<literal>missing</literal> means that the core was stored in a file, but
this file has since been removed.</para></listitem>
</varlistentry>
<varlistentry>
<term>EXE</term>
<listitem><para>The full path to the executable. For backtraces of scripts
this is the name of the interpreter.</para></listitem>
</varlistentry>
</variablelist>
2016-05-16 12:56:04 +03:00
<para>It's worth noting that different restrictions apply to
data saved in the journal and core dump files saved in
<filename>/var/lib/systemd/coredump</filename>, see overview in
<citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
Thus it may very well happen that a particular core dump is still listed
in the journal while its corresponding core dump file has already been
removed.</para></listitem>
2015-02-04 05:14:13 +03:00
</varlistentry>
<varlistentry>
<term><command>info</command></term>
2016-05-16 12:56:04 +03:00
<listitem><para>Show detailed information about core dumps
2015-02-04 05:14:13 +03:00
captured in the journal.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>dump</command></term>
2016-05-16 12:56:04 +03:00
<listitem><para>Extract the last core dump matching specified
characteristics. The core dump will be written on standard
2015-02-04 05:14:13 +03:00
output, unless an output file is specified with
2015-08-25 21:04:55 +03:00
<option>--output=</option>. </para></listitem>
2015-02-04 05:14:13 +03:00
</varlistentry>
<varlistentry>
<term><command>gdb</command></term>
2016-05-16 12:56:04 +03:00
<listitem><para>Invoke the GNU debugger on the last core dump
2015-02-04 05:14:13 +03:00
matching specified characteristics. </para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Matching</title>
<para>A match can be:</para>
<variablelist>
<varlistentry>
<term><replaceable>PID</replaceable></term>
<listitem><para>Process ID of the
process that dumped
core. An integer.</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>COMM</replaceable></term>
<listitem><para>Name of the executable (matches
<option>COREDUMP_COMM=</option>). Must not contain slashes.
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>EXE</replaceable></term>
<listitem><para>Path to the executable (matches
<option>COREDUMP_EXE=</option>). Must contain at least one
slash. </para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>MATCH</replaceable></term>
<listitem><para>General journalctl predicate (see
2015-02-04 05:14:13 +03:00
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>).
Must contain an equals sign (<literal>=</literal>).</para></listitem>
2015-02-04 05:14:13 +03:00
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Exit status</title>
<para>On success, 0 is returned; otherwise, a non-zero failure
2016-05-16 12:56:04 +03:00
code is returned. Not finding any matching core dumps is treated as
2015-02-04 05:14:13 +03:00
failure.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<example>
2016-05-16 12:56:04 +03:00
<title>List all the core dumps of a program named foo</title>
2015-02-04 05:14:13 +03:00
<programlisting># coredumpctl list foo</programlisting>
</example>
<example>
2016-05-16 12:56:04 +03:00
<title>Invoke gdb on the last core dump</title>
2015-02-04 05:14:13 +03:00
<programlisting># coredumpctl gdb</programlisting>
</example>
<example>
<title>Show information about a process that dumped core,
matching by its PID 6654</title>
<programlisting># coredumpctl info 6654</programlisting>
</example>
<example>
2016-05-16 12:56:04 +03:00
<title>Extract the last core dump of /usr/bin/bar to a file named
2015-02-04 05:14:13 +03:00
<filename noindex="true">bar.coredump</filename></title>
<programlisting># coredumpctl -o bar.coredump dump /usr/bin/bar</programlisting>
</example>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>