Merge pull request #4526 from keszybz/coredump-python

Collect interpreter backtraces in systemd-coredump

3 files changed, 49 insertions, 15 deletions

diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml
index 77b4dac51c..5f61e05f40 100644
--- a/man/coredump.conf.xml
+++ b/man/coredump.conf.xml
@@ -85,7 +85,7 @@
 
         <listitem><para>Controls where to store cores. One of <literal>none</literal>,
         <literal>external</literal>, and <literal>journal</literal>. When
-        <literal>none</literal>, the core dumps will be logged (included the traceback if
+        <literal>none</literal>, the core dumps will be logged (including the backtrace if
         possible), but not stored permanently. When <literal>external</literal> (the
         default), cores will be stored in <filename>/var/lib/systemd/coredump/</filename>.
         When <literal>journal</literal>, cores will be stored in the journal and rotated
diff --git a/man/sd-id128.xml b/man/sd-id128.xml
index 5f24feff8e..2e29cf91cb 100644
--- a/man/sd-id128.xml
+++ b/man/sd-id128.xml
@@ -47,6 +47,7 @@
     <refname>sd-id128</refname>
     <refname>sd_id128_t</refname>
     <refname>SD_ID128_MAKE</refname>
+    <refname>SD_ID128_MAKE_STR</refname>
     <refname>SD_ID128_NULL</refname>
     <refname>SD_ID128_CONST_STR</refname>
     <refname>SD_ID128_FORMAT_STR</refname>
@@ -113,12 +114,24 @@
     <para><function>SD_ID128_NULL</function> may be used to refer to the 128bit ID consisting of only NUL
     bytes.</para>
 
+    <para><function>SD_ID128_MAKE_STR()</function> is similar to <function>SD_ID128_MAKE()</function>, but creates a
+    <type>const char*</type> expression that can be conveniently used in message formats and such:</para>
+
+    <programlisting>#include &lt;stdio.h&gt;
+#define SD_MESSAGE_COREDUMP_STR SD_ID128_MAKE_STR(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1)
+
+int main(int argc, char **argv) {
+        puts("Match for coredumps: MESSAGE_ID=" SD_MESSAGE_COREDUMP_STR);
+}
+    </programlisting>
+
+
     <para><function>SD_ID128_CONST_STR()</function> may be used to
     convert constant 128-bit IDs into constant strings for output. The
     following example code will output the string
     "fc2e22bc6ee647b6b90729ab34a250b1":</para>
     <programlisting>int main(int argc, char *argv[]) {
-        puts(SD_ID128_CONST_STR(SD_MESSAGE_COREDUMP));
+        puts("Match for coredumps: %s", SD_ID128_CONST_STR(SD_MESSAGE_COREDUMP));
 }</programlisting>
 
     <para><function>SD_ID128_FORMAT_STR()</function> and
diff --git a/man/systemd-coredump.xml b/man/systemd-coredump.xml
index 4a1bc8b296..7243467dc2 100644
--- a/man/systemd-coredump.xml
+++ b/man/systemd-coredump.xml
@@ -52,14 +52,26 @@
 
   <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><command>systemd-coredump</command> is a system service that can acquire core dumps
-    from the kernel and handle them in various ways.</para>
+    <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
@@ -70,18 +82,20 @@
     if possible to the journal and store the core dump itself in an external file in
     <filename>/var/lib/systemd/coredump</filename>.</para>
 
-    <para>When the kernel invokes <command>systemd-coredump</command> to handle a core dump,
-    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 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>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 core dump will only be processed when the related resource limits are sufficient.
     </para>
+
+    <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="http://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>
@@ -91,7 +105,8 @@
     <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
     </para>
 
-    <para>In order to be used <command>systemd-coredump</command> must be configured in
+    <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>.
@@ -99,14 +114,20 @@
     <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
+    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><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><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