]>
Commit | Line | Data |
---|---|---|
514094f9 | 1 | <?xml version='1.0'?> |
3a54a157 | 2 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" |
eea10b26 | 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> |
db9ecf05 | 4 | <!-- SPDX-License-Identifier: LGPL-2.1-or-later --> |
5146e7e8 ZJS |
5 | |
6 | <refentry id="systemd-coredump" conditional='ENABLE_COREDUMP' | |
7 | xmlns:xi="http://www.w3.org/2001/XInclude"> | |
8 | ||
9 | <refentryinfo> | |
10 | <title>systemd-coredump</title> | |
11 | <productname>systemd</productname> | |
5146e7e8 ZJS |
12 | </refentryinfo> |
13 | ||
14 | <refmeta> | |
15 | <refentrytitle>systemd-coredump</refentrytitle> | |
16 | <manvolnum>8</manvolnum> | |
17 | </refmeta> | |
18 | ||
19 | <refnamediv> | |
20 | <refname>systemd-coredump</refname> | |
6dfde7ac ZJS |
21 | <refname>systemd-coredump.socket</refname> |
22 | <refname>systemd-coredump@.service</refname> | |
246ba4aa | 23 | <refpurpose>Acquire, save and process core dumps</refpurpose> |
5146e7e8 ZJS |
24 | </refnamediv> |
25 | ||
26 | <refsynopsisdiv> | |
12b42c76 | 27 | <para><filename>/usr/lib/systemd/systemd-coredump</filename></para> |
f6940bc3 | 28 | <para><filename>/usr/lib/systemd/systemd-coredump</filename> <option>--backtrace</option></para> |
6dfde7ac ZJS |
29 | <para><filename>systemd-coredump@.service</filename></para> |
30 | <para><filename>systemd-coredump.socket</filename></para> | |
5146e7e8 ZJS |
31 | </refsynopsisdiv> |
32 | ||
33 | <refsect1> | |
34 | <title>Description</title> | |
4f57f772 ZJS |
35 | <para><filename>systemd-coredump@.service</filename> is a system service to process core dumps. It will |
36 | log a summary of the event to | |
37 | <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, | |
38 | including information about the process identifier, owner, the signal that killed the process, and the | |
9d58abfa ZJS |
39 | stack trace if possible. It may also save the core dump for later processing. See the "Information about |
40 | the crashed process" section below.</para> | |
5146e7e8 | 41 | |
246ba4aa PM |
42 | <para>The behavior of a specific program upon reception of a signal is governed by a few |
43 | factors which are described in detail in | |
44 | <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>. | |
45 | In particular, the core dump will only be processed when the related resource limits are sufficient. | |
f3962329 | 46 | </para> |
f6940bc3 | 47 | |
4f57f772 ZJS |
48 | <para>Core dumps can be written to the journal or saved as a file. In both cases, they can be retrieved |
49 | for further processing, for example in | |
50 | <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>. | |
51 | See <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, | |
52 | in particular the <command>list</command> and <command>debug</command> verbs.</para> | |
53 | ||
54 | <para>By default, <command>systemd-coredump</command> will log the core dump to the journal, including a | |
55 | backtrace if possible, and store the core dump (an image of the memory contents of the process) itself in | |
56 | an external file in <filename>/var/lib/systemd/coredump</filename>. These core dumps are deleted after a | |
57 | few days by default; see <filename>/usr/lib/tmpfiles.d/systemd.conf</filename> for details. Note that the | |
58 | removal of core files from the file system and the purging of journal entries are independent, and the | |
59 | core file may be present without the journal entry, and journal entries may point to since-removed core | |
33360f35 ZJS |
60 | files. Some metadata is attached to core files in the form of extended attributes, so the core files are |
61 | useful for some purposes even without the full metadata available in the journal entry.</para> | |
4f57f772 | 62 | |
bba6046b LP |
63 | <para>For further details see <ulink url="https://systemd.io/COREDUMP">systemd Coredump |
64 | Handling</ulink>.</para> | |
65 | ||
4f57f772 ZJS |
66 | <refsect2> |
67 | <title>Invocation of <command>systemd-coredump</command></title> | |
68 | ||
69 | <para>The <command>systemd-coredump</command> executable does the actual work. It is invoked twice: | |
70 | once as the handler by the kernel, and the second time in the | |
71 | <filename>systemd-coredump@.service</filename> to actually write the data to the journal and process | |
72 | and save the core file.</para> | |
73 | ||
74 | <para>When the kernel invokes <command>systemd-coredump</command> to handle a core dump, it runs in | |
75 | privileged mode, and will connect to the socket created by the | |
76 | <filename>systemd-coredump.socket</filename> unit, which in turn will spawn an unprivileged | |
77 | <filename>systemd-coredump@.service</filename> instance to process the core dump. Hence | |
78 | <filename>systemd-coredump.socket</filename> and <filename>systemd-coredump@.service</filename> are | |
79 | helper units which do the actual processing of core dumps and are subject to normal service | |
80 | management.</para> | |
81 | ||
82 | <para>It is also possible to invoke <command>systemd-coredump</command> with | |
83 | <option>--backtrace</option> option. In this case, <command>systemd-coredump</command> expects a | |
84 | journal entry in the journal | |
717e92ce | 85 | <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink> |
4f57f772 ZJS |
86 | on standard input. The entry should contain a <varname>MESSAGE=</varname> field and any additional |
87 | metadata fields the caller deems reasonable. <command>systemd-coredump</command> will append additional | |
88 | metadata fields in the same way it does for core dumps received from the kernel. In this mode, no core | |
89 | dump is stored in the journal.</para> | |
90 | </refsect2> | |
246ba4aa | 91 | </refsect1> |
7382a3cc | 92 | |
246ba4aa PM |
93 | <refsect1> |
94 | <title>Configuration</title> | |
207194c6 | 95 | <para>For programs started by <command>systemd</command>, process resource limits can be set by directive |
96 | <varname>LimitCORE=</varname>, see | |
246ba4aa PM |
97 | <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. |
98 | </para> | |
99 | ||
f6940bc3 ZJS |
100 | <para>In order to be used by the kernel to handle core dumps, |
101 | <command>systemd-coredump</command> must be configured in | |
246ba4aa PM |
102 | <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
103 | parameter <varname>kernel.core_pattern</varname>. The syntax of this parameter is explained in | |
104 | <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>. | |
f95b0be7 | 105 | systemd installs the file <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> which configures |
246ba4aa PM |
106 | <varname>kernel.core_pattern</varname> accordingly. This file may be masked or overridden to use a different |
107 | setting following normal | |
108 | <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> | |
f6940bc3 ZJS |
109 | rules. If the sysctl configuration is modified, it must be updated in the kernel before it |
110 | takes effect, see | |
246ba4aa | 111 | <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
7382a3cc | 112 | and |
246ba4aa | 113 | <citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>. |
7382a3cc | 114 | </para> |
246ba4aa | 115 | |
207194c6 | 116 | <para>In order to be used in the <option>--backtrace</option> mode, an appropriate backtrace |
f6940bc3 | 117 | handler must be installed on the sender side. For example, in case of |
98e9d710 | 118 | <citerefentry project='die-net'><refentrytitle>python</refentrytitle><manvolnum>1</manvolnum></citerefentry>, this |
207194c6 | 119 | means a <varname>sys.excepthook</varname> must be installed, see |
a1174b22 | 120 | <ulink url="https://github.com/systemd/systemd-coredump-python">systemd-coredump-python</ulink>. |
f6940bc3 ZJS |
121 | </para> |
122 | ||
2dd67817 | 123 | <para>The behavior of <command>systemd-coredump</command> itself is configured through the configuration file |
246ba4aa PM |
124 | <filename>/etc/systemd/coredump.conf</filename> and corresponding snippets |
125 | <filename>/etc/systemd/coredump.conf.d/*.conf</filename>, see | |
126 | <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. A new | |
127 | instance of <command>systemd-coredump</command> is invoked upon receiving every core dump. Therefore, changes | |
128 | in these files will take effect the next time a core dump is received.</para> | |
129 | ||
130 | <para>Resources used by core dump files are restricted in two ways. Parameters like maximum size of acquired | |
131 | core dumps and files can be set in files <filename>/etc/systemd/coredump.conf</filename> and snippets mentioned | |
132 | above. In addition the storage time of core dump files is restricted by <command>systemd-tmpfiles</command>, | |
c6ef002b AJ |
133 | corresponding settings are by default in <filename>/usr/lib/tmpfiles.d/systemd.conf</filename>. The default is |
134 | to delete core dumps after a few days; see the above file for details.</para> | |
c8e053fb ZJS |
135 | |
136 | <refsect2> | |
137 | <title>Disabling coredump processing</title> | |
138 | ||
4f57f772 | 139 | <para>To disable potentially resource-intensive processing by <command>systemd-coredump</command>, set |
9b87ccd4 ZJS |
140 | <programlisting>Storage=none |
141 | ProcessSizeMax=0</programlisting> in | |
c8e053fb ZJS |
142 | <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. |
143 | </para> | |
144 | </refsect2> | |
246ba4aa PM |
145 | </refsect1> |
146 | ||
147 | <refsect1> | |
9d58abfa ZJS |
148 | <title>Information about the crashed process</title> |
149 | ||
150 | <para><citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> can | |
151 | be used to retrieve saved core dumps independently of their location, to display information, and to | |
152 | process them e.g. by passing to the GNU debugger (gdb).</para> | |
153 | ||
154 | <para>Data stored in the journal can be also viewed with | |
155 | <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> as usual | |
156 | (or from any other process, using the | |
157 | <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry> API). | |
158 | The relevant messages have <constant>MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1</constant>:</para> | |
159 | <programlisting>$ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose | |
160 | … | |
161 | MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 | |
162 | COREDUMP_PID=552351 | |
163 | COREDUMP_UID=1000 | |
164 | COREDUMP_GID=1000 | |
165 | COREDUMP_SIGNAL_NAME=SIGSEGV | |
166 | COREDUMP_SIGNAL=11 | |
167 | COREDUMP_TIMESTAMP=1614342930000000 | |
168 | COREDUMP_COMM=Web Content | |
169 | COREDUMP_EXE=/usr/lib64/firefox/firefox | |
170 | COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope | |
171 | COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser … | |
172 | COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-….scope | |
173 | COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web….552351.….zst | |
174 | … | |
175 | </programlisting> | |
176 | ||
177 | <para>The following fields are saved (if known) with the journal entry</para> | |
178 | ||
179 | <variablelist class='journal-directives'> | |
180 | <varlistentry> | |
181 | <term><varname>COREDUMP_UID=</varname></term> | |
182 | <term><varname>COREDUMP_PID=</varname></term> | |
183 | <term><varname>COREDUMP_GID=</varname></term> | |
40019c32 ZJS |
184 | <listitem><para>The process number (PID), owner user number (UID), and group number (GID) of the |
185 | crashed process.</para> | |
186 | ||
187 | <para>When the crashed process was part of a container (or in a process or user namespace in | |
188 | general), those are the values as seen <emphasis>outside</emphasis>, in the namespace where | |
189 | <filename>systemd-coredump</filename> is running.</para> | |
ec07c3c8 AK |
190 | |
191 | <xi:include href="version-info.xml" xpointer="v248"/> | |
9d58abfa ZJS |
192 | </listitem> |
193 | </varlistentry> | |
194 | ||
195 | <varlistentry> | |
196 | <term><varname>COREDUMP_TIMESTAMP=</varname></term> | |
e503019b | 197 | <listitem><para>The time of the crash as reported by the kernel (in μs since the epoch).</para> |
ec07c3c8 AK |
198 | |
199 | <xi:include href="version-info.xml" xpointer="v248"/> | |
9d58abfa ZJS |
200 | </listitem> |
201 | </varlistentry> | |
202 | ||
203 | <varlistentry> | |
204 | <term><varname>COREDUMP_RLIMIT=</varname></term> | |
205 | <listitem><para>The core file size soft resource limit, see | |
206 | <citerefentry project='man-pages'><refentrytitle>getrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>. | |
ec07c3c8 AK |
207 | </para> |
208 | ||
209 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
9d58abfa ZJS |
210 | </varlistentry> |
211 | ||
212 | <varlistentry> | |
213 | <term><varname>COREDUMP_UNIT=</varname></term> | |
214 | <term><varname>COREDUMP_SLICE=</varname></term> | |
215 | <listitem><para>The system unit and slice names.</para> | |
40019c32 ZJS |
216 | |
217 | <para>When the crashed process was in container, those are the units names | |
218 | <emphasis>outside</emphasis>, in the main system manager.</para> | |
ec07c3c8 AK |
219 | |
220 | <xi:include href="version-info.xml" xpointer="v248"/> | |
9d58abfa ZJS |
221 | </listitem> |
222 | </varlistentry> | |
223 | ||
224 | <varlistentry> | |
225 | <term><varname>COREDUMP_CGROUP=</varname></term> | |
a9d54de6 LP |
226 | |
227 | <listitem><para>The primary cgroup of the unit of the crashed process.</para> | |
228 | ||
229 | <para>When the crashed process was in a container, this is the full path, as seen outside of the | |
230 | container.</para> | |
231 | ||
232 | <xi:include href="version-info.xml" xpointer="v248"/> | |
233 | </listitem> | |
234 | </varlistentry> | |
235 | ||
236 | <varlistentry> | |
237 | <term><varname>COREDUMP_PROC_CGROUP=</varname></term> | |
9d58abfa ZJS |
238 | <listitem><para>Control group information in the format used in |
239 | <filename>/proc/self/cgroup</filename>. On systems with the unified cgroup hierarchy, this is a | |
240 | single path prefixed with <literal>0::</literal>, and multiple paths prefixed with controller numbers | |
40019c32 ZJS |
241 | on legacy systems.</para> |
242 | ||
243 | <para>When the crashed process was in a container, this is the full path, as seen outside of the | |
244 | container.</para> | |
ec07c3c8 AK |
245 | |
246 | <xi:include href="version-info.xml" xpointer="v248"/> | |
40019c32 | 247 | </listitem> |
9d58abfa ZJS |
248 | </varlistentry> |
249 | ||
250 | <varlistentry> | |
251 | <term><varname>COREDUMP_OWNER_UID=</varname></term> | |
252 | <term><varname>COREDUMP_USER_UNIT=</varname></term> | |
a9d54de6 | 253 | <term><varname>COREDUMP_SESSION=</varname></term> |
9d58abfa | 254 | <listitem><para>The numerical UID of the user owning the login session or systemd user unit of the |
0fd9bea3 | 255 | crashed process, the user manager unit, and the session identifier. All three fields are only present |
a9d54de6 | 256 | for user processes.</para> |
40019c32 ZJS |
257 | |
258 | <para>When the crashed process was in container, those are the values <emphasis>outside</emphasis>, | |
259 | in the main system.</para> | |
ec07c3c8 AK |
260 | |
261 | <xi:include href="version-info.xml" xpointer="v248"/> | |
40019c32 | 262 | </listitem> |
9d58abfa ZJS |
263 | </varlistentry> |
264 | ||
265 | <varlistentry> | |
266 | <term><varname>COREDUMP_SIGNAL_NAME=</varname></term> | |
267 | <term><varname>COREDUMP_SIGNAL=</varname></term> | |
268 | ||
c53e8b9d ZJS |
269 | <listitem><para>The terminating signal name (with the <literal>SIG</literal> prefix |
270 | <footnote><para><citerefentry | |
271 | project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
272 | expects signal names <emphasis>without</emphasis> the prefix; <citerefentry | |
273 | project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry> uses | |
274 | the prefix; all systemd tools accept signal names both with and without the prefix. | |
275 | </para></footnote>) and numerical value. (Both are included because signal numbers vary by | |
276 | architecture.)</para> | |
ec07c3c8 AK |
277 | |
278 | <xi:include href="version-info.xml" xpointer="v248"/> | |
9d58abfa ZJS |
279 | </listitem> |
280 | </varlistentry> | |
281 | ||
282 | <varlistentry> | |
283 | <term><varname>COREDUMP_CWD=</varname></term> | |
284 | <term><varname>COREDUMP_ROOT=</varname></term> | |
285 | ||
286 | <listitem><para>The current working directory and root directory of the crashed process.</para> | |
40019c32 ZJS |
287 | |
288 | <para>When the crashed process is in a container, those paths are relative to the root of the | |
289 | container's mount namespace.</para> | |
ec07c3c8 AK |
290 | |
291 | <xi:include href="version-info.xml" xpointer="v248"/> | |
9d58abfa ZJS |
292 | </listitem> |
293 | </varlistentry> | |
294 | ||
295 | <varlistentry> | |
296 | <term><varname>COREDUMP_OPEN_FDS=</varname></term> | |
297 | ||
298 | <listitem><para>Information about open file descriptors, in the following format:</para> | |
299 | <programlisting><replaceable>fd</replaceable>:<replaceable>/path/to/file</replaceable> | |
300 | pos: ... | |
301 | flags: ... | |
302 | ... | |
303 | ||
304 | <replaceable>fd</replaceable>:<replaceable>/path/to/file</replaceable> | |
305 | pos: ... | |
306 | flags: ... | |
307 | ... | |
308 | </programlisting> | |
309 | ||
310 | <para>The first line contains the file descriptor number <replaceable>fd</replaceable> and the path, | |
311 | while subsequent lines show the contents of | |
312 | <filename>/proc/<replaceable>pid</replaceable>/fdinfo/<replaceable>fd</replaceable></filename>. | |
ec07c3c8 AK |
313 | </para> |
314 | ||
315 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
9d58abfa ZJS |
316 | </varlistentry> |
317 | ||
318 | <varlistentry> | |
9d58abfa | 319 | <term><varname>COREDUMP_EXE=</varname></term> |
40019c32 ZJS |
320 | |
321 | <listitem><para>The destination of the <filename>/proc/<replaceable>pid</replaceable>/exe</filename> | |
322 | symlink.</para> | |
323 | ||
324 | <para>When the crashed process is in a container, that path is relative to the root of the | |
ec07c3c8 AK |
325 | container's mount namespace.</para> |
326 | ||
327 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
40019c32 ZJS |
328 | </varlistentry> |
329 | ||
330 | <varlistentry> | |
a9d54de6 | 331 | <term><varname>COREDUMP_CMDLINE=</varname></term> |
40019c32 | 332 | <term><varname>COREDUMP_COMM=</varname></term> |
a9d54de6 LP |
333 | <term><varname>COREDUMP_ENVIRON=</varname></term> |
334 | <term><varname>COREDUMP_PROC_AUXV=</varname></term> | |
9d58abfa | 335 | <term><varname>COREDUMP_PROC_LIMITS=</varname></term> |
a9d54de6 | 336 | <term><varname>COREDUMP_PROC_MAPS=</varname></term> |
9d58abfa | 337 | <term><varname>COREDUMP_PROC_MOUNTINFO=</varname></term> |
a9d54de6 | 338 | <term><varname>COREDUMP_PROC_STATUS=</varname></term> |
9d58abfa ZJS |
339 | |
340 | <listitem><para>Fields that map the per-process entries in the <filename>/proc/</filename> | |
a9d54de6 LP |
341 | filesystem: <filename>/proc/<replaceable>pid</replaceable>/cmdline</filename> (the command line of |
342 | the crashed process), <filename>/proc/<replaceable>pid</replaceable>/comm</filename> (the command | |
343 | name associated with the process), <filename>/proc/<replaceable>pid</replaceable>/environ</filename> | |
344 | (the environment block of the crashed process), | |
345 | <filename>/proc/<replaceable>pid</replaceable>/auxv</filename> (the auxiliary vector of the crashed | |
346 | process, see <citerefentry | |
347 | project='man-pages'><refentrytitle>getauxval</refentrytitle><manvolnum>3</manvolnum></citerefentry>), | |
9d58abfa | 348 | <filename>/proc/<replaceable>pid</replaceable>/limits</filename> (the soft and hard resource limits), |
a9d54de6 LP |
349 | <filename>/proc/<replaceable>pid</replaceable>/maps</filename> (memory regions visible to the process |
350 | and their access permissions), <filename>/proc/<replaceable>pid</replaceable>/mountinfo</filename> | |
351 | (mount points in the process's mount namespace), | |
352 | <filename>/proc/<replaceable>pid</replaceable>/status</filename> (various metadata about the | |
353 | process).</para> | |
9d58abfa ZJS |
354 | |
355 | <para>See | |
356 | <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry> | |
ec07c3c8 AK |
357 | for more information.</para> |
358 | ||
359 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
9d58abfa ZJS |
360 | </varlistentry> |
361 | ||
362 | <varlistentry> | |
363 | <term><varname>COREDUMP_HOSTNAME=</varname></term> | |
364 | ||
40019c32 ZJS |
365 | <listitem><para>The system hostname.</para> |
366 | ||
367 | <para>When the crashed process was in container, this is the container hostname.</para> | |
ec07c3c8 AK |
368 | |
369 | <xi:include href="version-info.xml" xpointer="v248"/> | |
40019c32 | 370 | </listitem> |
9d58abfa ZJS |
371 | </varlistentry> |
372 | ||
373 | <varlistentry> | |
374 | <term><varname>COREDUMP_CONTAINER_CMDLINE=</varname></term> | |
375 | ||
7c52d523 | 376 | <listitem><para>For processes running in a container, the command line of the process spawning the |
ec07c3c8 AK |
377 | container (the first parent process with a different mount namespace).</para> |
378 | ||
379 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
9d58abfa ZJS |
380 | </varlistentry> |
381 | ||
382 | <varlistentry> | |
383 | <term><varname>COREDUMP=</varname></term> | |
384 | ||
385 | <listitem><para>When the core is stored in the journal, the core image itself.</para> | |
ec07c3c8 AK |
386 | |
387 | <xi:include href="version-info.xml" xpointer="v248"/> | |
9d58abfa ZJS |
388 | </listitem> |
389 | </varlistentry> | |
390 | ||
391 | <varlistentry> | |
392 | <term><varname>COREDUMP_FILENAME=</varname></term> | |
393 | ||
3d62af7d | 394 | <listitem><para>When the core is stored externally, the path to the core file.</para> |
ec07c3c8 AK |
395 | |
396 | <xi:include href="version-info.xml" xpointer="v248"/> | |
9d58abfa ZJS |
397 | </listitem> |
398 | </varlistentry> | |
399 | ||
400 | <varlistentry> | |
401 | <term><varname>COREDUMP_TRUNCATED=</varname></term> | |
402 | ||
403 | <listitem><para>Set to <literal>1</literal> when the saved coredump was truncated. (A partial core | |
404 | image may still be processed by some tools, though obviously not all information is available.) | |
ec07c3c8 AK |
405 | </para> |
406 | ||
407 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
9d58abfa ZJS |
408 | </varlistentry> |
409 | ||
c546154a | 410 | <varlistentry> |
671769c9 LB |
411 | <term><varname>COREDUMP_PACKAGE_NAME=</varname></term> |
412 | <term><varname>COREDUMP_PACKAGE_VERSION=</varname></term> | |
413 | <term><varname>COREDUMP_PACKAGE_JSON=</varname></term> | |
c546154a LB |
414 | |
415 | <listitem><para>If the executable contained .package metadata ELF notes, they will be | |
416 | parsed and attached. The <varname>package</varname> and <varname>packageVersion</varname> | |
f1a5c566 | 417 | of the 'main' ELF module (ie: the executable) will be appended individually. The |
c546154a LB |
418 | JSON-formatted content of all modules will be appended as a single JSON object, each with |
419 | the module name as the key. For more information about this metadata format and content, see | |
420 | <ulink url="https://systemd.io/COREDUMP_PACKAGE_METADATA/">the coredump metadata spec</ulink>.</para> | |
ec07c3c8 AK |
421 | |
422 | <xi:include href="version-info.xml" xpointer="v249"/> | |
c546154a LB |
423 | </listitem> |
424 | </varlistentry> | |
425 | ||
9d58abfa ZJS |
426 | <varlistentry> |
427 | <term><varname>MESSAGE=</varname></term> | |
428 | ||
429 | <listitem><para>The message generated by <command>systemd-coredump</command> that includes the | |
430 | backtrace if it was successfully generated. When <command>systemd-coredump</command> is invoked with | |
ec07c3c8 AK |
431 | <option>--backtrace</option>, this field is provided by the caller.</para> |
432 | ||
433 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
9d58abfa ZJS |
434 | </varlistentry> |
435 | </variablelist> | |
436 | ||
437 | <para>Various other fields exist in the journal entry, but pertain to the logging process, | |
438 | i.e. <command>systemd-coredump</command>, not the crashed process. See | |
439 | <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>. | |
440 | </para> | |
441 | ||
442 | <para>The following fields are saved (if known) with the external file listed in | |
443 | <varname>COREDUMP_FILENAME=</varname> as extended attributes:</para> | |
444 | ||
445 | <variablelist> | |
446 | <varlistentry> | |
447 | <term><varname>user.coredump.pid</varname></term> | |
448 | <term><varname>user.coredump.uid</varname></term> | |
449 | <term><varname>user.coredump.gid</varname></term> | |
450 | <term><varname>user.coredump.signal</varname></term> | |
451 | <term><varname>user.coredump.timestamp</varname></term> | |
452 | <term><varname>user.coredump.rlimit</varname></term> | |
453 | <term><varname>user.coredump.hostname</varname></term> | |
454 | <term><varname>user.coredump.comm</varname></term> | |
455 | <term><varname>user.coredump.exe</varname></term> | |
456 | ||
457 | <listitem><para>Those are the same as <varname>COREDUMP_PID=</varname>, | |
458 | <varname>COREDUMP_UID=</varname>, <varname>COREDUMP_GID=</varname>, | |
459 | <varname>COREDUMP_SIGNAL=</varname>, <varname>COREDUMP_TIMESTAMP=</varname>, | |
460 | <varname>COREDUMP_RLIMIT=</varname>, <varname>COREDUMP_HOSTNAME=</varname>, | |
461 | <varname>COREDUMP_COMM=</varname>, and <varname>COREDUMP_EXE=</varname>, described above. | |
ec07c3c8 AK |
462 | </para> |
463 | ||
464 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
9d58abfa ZJS |
465 | </varlistentry> |
466 | </variablelist> | |
467 | ||
468 | <para>Those can be viewed using | |
469 | <citerefentry project='man-pages'><refentrytitle>getfattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>. | |
470 | For the core file described in the journal entry shown above: | |
471 | <programlisting>$ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web….552351.….zst | |
472 | # file: /var/lib/systemd/coredump/core.Web….552351.….zst | |
473 | user.coredump.pid="552351" | |
474 | user.coredump.uid="1000" | |
475 | user.coredump.gid="1000" | |
476 | user.coredump.signal="11" | |
477 | user.coredump.timestamp="1614342930000000" | |
478 | user.coredump.comm="Web Content" | |
479 | user.coredump.exe="/usr/lib64/firefox/firefox" | |
480 | … | |
481 | </programlisting> | |
482 | </para> | |
5146e7e8 ZJS |
483 | </refsect1> |
484 | ||
485 | <refsect1> | |
486 | <title>See Also</title> | |
13a69c12 DT |
487 | <para><simplelist type="inline"> |
488 | <member><citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry></member> | |
489 | <member><citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
490 | <member><citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
491 | <member><citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
492 | <member><citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry></member> | |
493 | <member><citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry></member> | |
494 | <member><citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
495 | <member><ulink url="https://systemd.io/COREDUMP">systemd Coredump Handling</ulink></member> | |
496 | </simplelist></para> | |
5146e7e8 ZJS |
497 | </refsect1> |
498 | </refentry> |