]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd.journal-fields.xml
Merge pull request #6917 from keszybz/restore-some-tests
[thirdparty/systemd.git] / man / systemd.journal-fields.xml
1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4
5 <!--
6 This file is part of systemd.
7
8 Copyright 2010 Lennart Poettering
9
10 systemd is free software; you can redistribute it and/or modify it
11 under the terms of the GNU Lesser General Public License as published by
12 the Free Software Foundation; either version 2.1 of the License, or
13 (at your option) any later version.
14
15 systemd is distributed in the hope that it will be useful, but
16 WITHOUT ANY WARRANTY; without even the implied warranty of
17 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
18 Lesser General Public License for more details.
19
20 You should have received a copy of the GNU Lesser General Public License
21 along with systemd; If not, see <http://www.gnu.org/licenses/>.
22 -->
23
24 <refentry id="systemd.journal-fields">
25
26 <refentryinfo>
27 <title>systemd.journal-fields</title>
28 <productname>systemd</productname>
29
30 <authorgroup>
31 <author>
32 <contrib>Developer</contrib>
33 <firstname>Lennart</firstname>
34 <surname>Poettering</surname>
35 <email>lennart@poettering.net</email>
36 </author>
37 </authorgroup>
38 </refentryinfo>
39
40 <refmeta>
41 <refentrytitle>systemd.journal-fields</refentrytitle>
42 <manvolnum>7</manvolnum>
43 </refmeta>
44
45 <refnamediv>
46 <refname>systemd.journal-fields</refname>
47 <refpurpose>Special journal fields</refpurpose>
48 </refnamediv>
49
50 <refsect1>
51 <title>Description</title>
52
53 <para>Entries in the journal resemble an environment block in
54 their syntax but with fields that can include binary data.
55 Primarily, fields are formatted UTF-8 text strings, and binary
56 formatting is used only where formatting as UTF-8 text strings
57 makes little sense. New fields may freely be defined by
58 applications, but a few fields have special meaning. All fields
59 with special meanings are optional. In some cases, fields may
60 appear more than once per entry.</para>
61 </refsect1>
62
63 <refsect1>
64 <title>User Journal Fields</title>
65
66 <para>User fields are fields that are directly passed from clients
67 and stored in the journal.</para>
68
69 <variablelist class='journal-directives'>
70 <varlistentry>
71 <term><varname>MESSAGE=</varname></term>
72 <listitem>
73 <para>The human-readable message string for this entry. This
74 is supposed to be the primary text shown to the user. It is
75 usually not translated (but might be in some cases), and is
76 not supposed to be parsed for metadata.</para>
77 </listitem>
78 </varlistentry>
79
80 <varlistentry>
81 <term><varname>MESSAGE_ID=</varname></term>
82 <listitem>
83 <para>A 128-bit message identifier ID for recognizing
84 certain message types, if this is desirable. This should
85 contain a 128-bit ID formatted as a lower-case hexadecimal
86 string, without any separating dashes or suchlike. This is
87 recommended to be a UUID-compatible ID, but this is not
88 enforced, and formatted differently. Developers can generate
89 a new ID for this purpose with <command>journalctl
90 <option>--new-id128</option></command>.
91 </para>
92 </listitem>
93 </varlistentry>
94
95 <varlistentry>
96 <term><varname>PRIORITY=</varname></term>
97 <listitem>
98 <para>A priority value between 0 (<literal>emerg</literal>)
99 and 7 (<literal>debug</literal>) formatted as a decimal
100 string. This field is compatible with syslog's priority
101 concept.</para>
102 </listitem>
103 </varlistentry>
104
105 <varlistentry>
106 <term><varname>CODE_FILE=</varname></term>
107 <term><varname>CODE_LINE=</varname></term>
108 <term><varname>CODE_FUNC=</varname></term>
109 <listitem>
110 <para>The code location generating this message, if known.
111 Contains the source filename, the line number and the
112 function name.</para>
113 </listitem>
114 </varlistentry>
115
116 <varlistentry>
117 <term><varname>ERRNO=</varname></term>
118 <listitem>
119 <para>The low-level Unix error number causing this entry, if
120 any. Contains the numeric value of
121 <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
122 formatted as a decimal string.</para>
123 </listitem>
124 </varlistentry>
125
126 <varlistentry>
127 <term><varname>SYSLOG_FACILITY=</varname></term>
128 <term><varname>SYSLOG_IDENTIFIER=</varname></term>
129 <term><varname>SYSLOG_PID=</varname></term>
130 <listitem>
131 <para>Syslog compatibility fields containing the facility
132 (formatted as decimal string), the identifier string (i.e.
133 "tag"), and the client PID. (Note that the tag is usually
134 derived from glibc's
135 <varname>program_invocation_short_name</varname> variable,
136 see
137 <citerefentry project='die-net'><refentrytitle>program_invocation_short_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.)</para>
138 </listitem>
139
140 </varlistentry>
141 </variablelist>
142 </refsect1>
143
144 <refsect1>
145 <title>Trusted Journal Fields</title>
146
147 <para>Fields prefixed with an underscore are trusted fields, i.e.
148 fields that are implicitly added by the journal and cannot be
149 altered by client code.</para>
150
151 <variablelist class='journal-directives'>
152 <varlistentry>
153 <term><varname>_PID=</varname></term>
154 <term><varname>_UID=</varname></term>
155 <term><varname>_GID=</varname></term>
156 <listitem>
157 <para>The process, user, and group ID of the process the
158 journal entry originates from formatted as a decimal
159 string. Note that entries obtained via <literal>stdout</literal> or
160 <literal>stderr</literal> of forked processes will contain credentials valid for a parent
161 process (that initiated the connection to <command>systemd-journald</command>).</para>
162 </listitem>
163 </varlistentry>
164
165 <varlistentry>
166 <term><varname>_COMM=</varname></term>
167 <term><varname>_EXE=</varname></term>
168 <term><varname>_CMDLINE=</varname></term>
169 <listitem>
170 <para>The name, the executable path, and the command line of
171 the process the journal entry originates from.</para>
172 </listitem>
173 </varlistentry>
174
175 <varlistentry>
176 <term><varname>_CAP_EFFECTIVE=</varname></term>
177 <listitem>
178 <para>The effective
179 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
180 of the process the journal entry originates from.</para>
181 </listitem>
182 </varlistentry>
183
184 <varlistentry>
185 <term><varname>_AUDIT_SESSION=</varname></term>
186 <term><varname>_AUDIT_LOGINUID=</varname></term>
187 <listitem>
188 <para>The session and login UID of the process the journal
189 entry originates from, as maintained by the kernel audit
190 subsystem.</para>
191 </listitem>
192 </varlistentry>
193
194 <varlistentry>
195 <term><varname>_SYSTEMD_CGROUP=</varname></term>
196 <term><varname>_SYSTEMD_SESSION=</varname></term>
197 <term><varname>_SYSTEMD_UNIT=</varname></term>
198 <term><varname>_SYSTEMD_USER_UNIT=</varname></term>
199 <term><varname>_SYSTEMD_OWNER_UID=</varname></term>
200 <term><varname>_SYSTEMD_SLICE=</varname></term>
201
202 <listitem>
203 <para>The control group path in the systemd hierarchy, the
204 systemd session ID (if any), the systemd unit name (if any),
205 the systemd user session unit name (if any), the owner UID
206 of the systemd session (if any) and the systemd slice unit
207 of the process the journal entry originates from.</para>
208 </listitem>
209 </varlistentry>
210
211 <varlistentry>
212 <term><varname>_SELINUX_CONTEXT=</varname></term>
213 <listitem>
214 <para>The SELinux security context (label) of the process
215 the journal entry originates from.</para>
216 </listitem>
217 </varlistentry>
218
219 <varlistentry>
220 <term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term>
221 <listitem>
222 <para>The earliest trusted timestamp of the message, if any
223 is known that is different from the reception time of the
224 journal. This is the time in microseconds since the epoch
225 UTC, formatted as a decimal string.</para>
226 </listitem>
227 </varlistentry>
228
229 <varlistentry>
230 <term><varname>_BOOT_ID=</varname></term>
231 <listitem>
232 <para>The kernel boot ID for the boot the message was
233 generated in, formatted as a 128-bit hexadecimal
234 string.</para>
235 </listitem>
236 </varlistentry>
237
238 <varlistentry>
239 <term><varname>_MACHINE_ID=</varname></term>
240 <listitem>
241 <para>The machine ID of the originating host, as available
242 in
243 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
244 </listitem>
245 </varlistentry>
246
247 <varlistentry>
248 <term><varname>_SYSTEMD_INVOCATION_ID=</varname></term>
249 <listitem>
250 <para>The invocation ID for the runtime cycle of the unit
251 the message was generated in, as available to processes
252 of the unit in <varname>$INVOCATION_ID</varname> (see
253 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para>
254 </listitem>
255 </varlistentry>
256
257 <varlistentry>
258 <term><varname>_HOSTNAME=</varname></term>
259 <listitem>
260 <para>The name of the originating host.</para>
261 </listitem>
262 </varlistentry>
263
264 <varlistentry>
265 <term><varname>_TRANSPORT=</varname></term>
266 <listitem>
267 <para>How the entry was received by the journal service.
268 Valid transports are:
269 </para>
270 <variablelist>
271 <varlistentry>
272 <term>
273 <option>audit</option>
274 </term>
275 <listitem>
276 <para>for those read from the kernel audit subsystem
277 </para>
278 </listitem>
279 </varlistentry>
280
281 <varlistentry>
282 <term>
283 <option>driver</option>
284 </term>
285 <listitem>
286 <para>for internally generated messages
287 </para>
288 </listitem>
289 </varlistentry>
290
291 <varlistentry>
292 <term>
293 <option>syslog</option>
294 </term>
295 <listitem>
296 <para>for those received via the local syslog socket
297 with the syslog protocol
298 </para>
299 </listitem>
300 </varlistentry>
301
302 <varlistentry>
303 <term>
304 <option>journal</option>
305 </term>
306 <listitem>
307 <para>for those received via the native journal
308 protocol
309 </para>
310 </listitem>
311 </varlistentry>
312
313 <varlistentry>
314 <term>
315 <option>stdout</option>
316 </term>
317 <listitem>
318 <para>for those read from a service's standard output
319 or error output
320 </para>
321 </listitem>
322 </varlistentry>
323
324 <varlistentry>
325 <term>
326 <option>kernel</option>
327 </term>
328 <listitem>
329 <para>for those read from the kernel
330 </para>
331 </listitem>
332 </varlistentry>
333 </variablelist>
334 </listitem>
335 </varlistentry>
336 <varlistentry>
337 <term><varname>_STREAM_ID=</varname></term>
338 <listitem>
339 <para>Only applies to <literal>_TRANSPORT=stream</literal> records: specifies a randomized 128bit ID assigned
340 to the stream connection when it was first created. This ID is useful to reconstruct individual log streams
341 from the log records: all log records carrying the same stream ID originate from the same stream.</para>
342 </listitem>
343 </varlistentry>
344 <varlistentry>
345 <term><varname>_LINE_BREAK=</varname></term>
346 <listitem>
347 <para>Only applies to <literal>_TRANSPORT=stream</literal> records: indicates that the log message in the
348 standard output/error stream was not terminated with a normal newline character (<literal>\n</literal>,
349 i.e. ASCII 10). Specifically, when set this field is one of <option>nul</option> (in case the line was
350 terminated by a NUL byte), <option>line-max</option> (in case the maximum log line length was reached, as
351 configured with <varname>LineMax=</varname> in
352 <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>) or
353 <option>eof</option> (if this was the last log record of a stream and the stream ended without a final
354 newline character). Note that this record is not generated when a normal newline character was used for
355 marking the log line end.</para>
356 </listitem>
357 </varlistentry>
358 </variablelist>
359 </refsect1>
360
361 <refsect1>
362 <title>Kernel Journal Fields</title>
363
364 <para>Kernel fields are fields that are used by messages
365 originating in the kernel and stored in the journal.</para>
366
367 <variablelist class='journal-directives'>
368 <varlistentry>
369 <term><varname>_KERNEL_DEVICE=</varname></term>
370 <listitem>
371 <para>The kernel device name. If the entry is associated to
372 a block device, the major and minor of the device node,
373 separated by <literal>:</literal> and prefixed by
374 <literal>b</literal>. Similar for character devices but
375 prefixed by <literal>c</literal>. For network devices, this
376 is the interface index prefixed by <literal>n</literal>. For
377 all other devices, this is the subsystem name prefixed by
378 <literal>+</literal>, followed by <literal>:</literal>,
379 followed by the kernel device name.</para>
380 </listitem>
381 </varlistentry>
382 <varlistentry>
383 <term><varname>_KERNEL_SUBSYSTEM=</varname></term>
384 <listitem>
385 <para>The kernel subsystem name.</para>
386 </listitem>
387 </varlistentry>
388 <varlistentry>
389 <term><varname>_UDEV_SYSNAME=</varname></term>
390 <listitem>
391 <para>The kernel device name as it shows up in the device
392 tree below <filename>/sys</filename>.</para>
393 </listitem>
394 </varlistentry>
395 <varlistentry>
396 <term><varname>_UDEV_DEVNODE=</varname></term>
397 <listitem>
398 <para>The device node path of this device in
399 <filename>/dev</filename>.</para>
400 </listitem>
401 </varlistentry>
402 <varlistentry>
403 <term><varname>_UDEV_DEVLINK=</varname></term>
404 <listitem>
405 <para>Additional symlink names pointing to the device node
406 in <filename>/dev</filename>. This field is frequently set
407 more than once per entry.</para>
408 </listitem>
409 </varlistentry>
410 </variablelist>
411 </refsect1>
412
413 <refsect1>
414 <title>Fields to log on behalf of a different program</title>
415
416 <para>Fields in this section are used by programs to specify that
417 they are logging on behalf of another program or unit.
418 </para>
419
420 <para>Fields used by the <command>systemd-coredump</command>
421 coredump kernel helper:
422 </para>
423
424 <variablelist class='journal-directives'>
425 <varlistentry>
426 <term><varname>COREDUMP_UNIT=</varname></term>
427 <term><varname>COREDUMP_USER_UNIT=</varname></term>
428 <listitem>
429 <para>Used to annotate messages containing coredumps from
430 system and session units. See
431 <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
432 </para>
433 </listitem>
434 </varlistentry>
435 </variablelist>
436
437 <para>Privileged programs (currently UID 0) may attach
438 <varname>OBJECT_PID=</varname> to a message. This will instruct
439 <command>systemd-journald</command> to attach additional fields on
440 behalf of the caller:</para>
441
442 <variablelist class='journal-directives'>
443 <varlistentry>
444 <term><varname>OBJECT_PID=<replaceable>PID</replaceable></varname></term>
445 <listitem>
446 <para>PID of the program that this message pertains to.
447 </para>
448 </listitem>
449 </varlistentry>
450
451 <varlistentry>
452 <term><varname>OBJECT_UID=</varname></term>
453 <term><varname>OBJECT_GID=</varname></term>
454 <term><varname>OBJECT_COMM=</varname></term>
455 <term><varname>OBJECT_EXE=</varname></term>
456 <term><varname>OBJECT_CMDLINE=</varname></term>
457 <term><varname>OBJECT_AUDIT_SESSION=</varname></term>
458 <term><varname>OBJECT_AUDIT_LOGINUID=</varname></term>
459 <term><varname>OBJECT_SYSTEMD_CGROUP=</varname></term>
460 <term><varname>OBJECT_SYSTEMD_SESSION=</varname></term>
461 <term><varname>OBJECT_SYSTEMD_OWNER_UID=</varname></term>
462 <term><varname>OBJECT_SYSTEMD_UNIT=</varname></term>
463 <term><varname>OBJECT_SYSTEMD_USER_UNIT=</varname></term>
464 <listitem>
465 <para>These are additional fields added automatically by
466 <command>systemd-journald</command>. Their meaning is the
467 same as
468 <varname>_UID=</varname>,
469 <varname>_GID=</varname>,
470 <varname>_COMM=</varname>,
471 <varname>_EXE=</varname>,
472 <varname>_CMDLINE=</varname>,
473 <varname>_AUDIT_SESSION=</varname>,
474 <varname>_AUDIT_LOGINUID=</varname>,
475 <varname>_SYSTEMD_CGROUP=</varname>,
476 <varname>_SYSTEMD_SESSION=</varname>,
477 <varname>_SYSTEMD_UNIT=</varname>,
478 <varname>_SYSTEMD_USER_UNIT=</varname>, and
479 <varname>_SYSTEMD_OWNER_UID=</varname>
480 as described above, except that the process identified by
481 <replaceable>PID</replaceable> is described, instead of the
482 process which logged the message.</para>
483 </listitem>
484 </varlistentry>
485 </variablelist>
486
487 </refsect1>
488
489 <refsect1>
490 <title>Address Fields</title>
491
492 <para>During serialization into external formats, such as the
493 <ulink
494 url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal
495 Export Format</ulink> or the <ulink
496 url="https://www.freedesktop.org/wiki/Software/systemd/json">Journal
497 JSON Format</ulink>, the addresses of journal entries are
498 serialized into fields prefixed with double underscores. Note that
499 these are not proper fields when stored in the journal but for
500 addressing metadata of entries. They cannot be written as part of
501 structured log entries via calls such as
502 <citerefentry><refentrytitle>sd_journal_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
503 They may also not be used as matches for
504 <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry></para>
505
506 <variablelist class='journal-directives'>
507 <varlistentry>
508 <term><varname>__CURSOR=</varname></term>
509 <listitem>
510 <para>The cursor for the entry. A cursor is an opaque text
511 string that uniquely describes the position of an entry in
512 the journal and is portable across machines, platforms and
513 journal files.
514 </para>
515 </listitem>
516 </varlistentry>
517
518 <varlistentry>
519 <term><varname>__REALTIME_TIMESTAMP=</varname></term>
520 <listitem>
521 <para>The wallclock time
522 (<constant>CLOCK_REALTIME</constant>) at the point in time
523 the entry was received by the journal, in microseconds since
524 the epoch UTC, formatted as a decimal string. This has
525 different properties from
526 <literal>_SOURCE_REALTIME_TIMESTAMP=</literal>, as it is
527 usually a bit later but more likely to be monotonic.
528 </para>
529 </listitem>
530 </varlistentry>
531
532 <varlistentry>
533 <term><varname>__MONOTONIC_TIMESTAMP=</varname></term>
534 <listitem>
535 <para>The monotonic time
536 (<constant>CLOCK_MONOTONIC</constant>) at the point in time
537 the entry was received by the journal in microseconds,
538 formatted as a decimal string. To be useful as an address
539 for the entry, this should be combined with the boot ID in
540 <literal>_BOOT_ID=</literal>.
541 </para>
542 </listitem>
543 </varlistentry>
544 </variablelist>
545 </refsect1>
546
547 <refsect1>
548 <title>See Also</title>
549 <para>
550 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
551 <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
552 <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
553 <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
554 <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
555 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
556 </para>
557 </refsect1>
558
559 </refentry>