<?xml version='1.0'?> <!--*-nxml-*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+<!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+
--->
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="systemd.journal-fields">
<refsect1>
<title>Description</title>
- <para>Entries in the journal resemble an environment block in
- their syntax but with fields that can include binary data.
- Primarily, fields are formatted UTF-8 text strings, and binary
- formatting is used only where formatting as UTF-8 text strings
- makes little sense. New fields may freely be defined by
- applications, but a few fields have special meaning. All fields
- with special meanings are optional. In some cases, fields may
- appear more than once per entry.</para>
+ <para>Entries in the journal (as written by
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
+ resemble a UNIX process environment block in syntax but with fields that may include binary data.
+ Primarily, fields are formatted UTF-8 text strings, and binary encoding is used only where formatting as
+ UTF-8 text strings makes little sense. New fields may freely be defined by applications, but a few fields
+ have special meanings. All fields with special meanings are optional. In some cases, fields may appear
+ more than once per entry.</para>
</refsect1>
<refsect1>
<varlistentry>
<term><varname>MESSAGE_ID=</varname></term>
<listitem>
- <para>A 128-bit message identifier ID for recognizing
- certain message types, if this is desirable. This should
- contain a 128-bit ID formatted as a lower-case hexadecimal
- string, without any separating dashes or suchlike. This is
- recommended to be a UUID-compatible ID, but this is not
- enforced, and formatted differently. Developers can generate
- a new ID for this purpose with <command>journalctl
- <option>--new-id128</option></command>.
+ <para>A 128-bit message identifier ID for recognizing certain message types, if this is desirable. This
+ should contain a 128-bit ID formatted as a lower-case hexadecimal string, without any separating dashes or
+ suchlike. This is recommended to be a UUID-compatible ID, but this is not enforced, and formatted
+ differently. Developers can generate a new ID for this purpose with <command>systemd-id128 new</command>.
</para>
</listitem>
</varlistentry>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>INVOCATION_ID=</varname></term>
+ <term><varname>USER_INVOCATION_ID=</varname></term>
+ <listitem>
+ <para>A randomized, unique 128-bit ID identifying each runtime cycle of the unit. This is different from
+ <varname>_SYSTEMD_INVOCATION_ID</varname> in that it is only used for messages coming from systemd code
+ (e.g. logs from the system/user manager or from forked processes performing systemd-related setup).</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>SYSLOG_FACILITY=</varname></term>
<term><varname>SYSLOG_IDENTIFIER=</varname></term>
usually derived from glibc's
<varname>program_invocation_short_name</varname> variable, see
<citerefentry project='die-net'><refentrytitle>program_invocation_short_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.)</para>
+ <para>Note that the journal service does not validate the values of any structured
+ journal fields whose name is not prefixed with an underscore, and this includes any
+ syslog related fields such as these. Hence, applications that supply a facility, PID,
+ or log level are expected to do so properly formatted, i.e. as numeric integers formatted
+ as decimal strings.</para>
</listitem>
</varlistentry>
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><varname>DOCUMENTATION=</varname></term>
+ <listitem>
+ <para>A documentation URL with further information about the topic of the log message. Tools such
+ as <command>journalctl</command> will include a hyperlink to an URL specified this way in their
+ output. Should be a <literal>http://</literal>, <literal>https://</literal>,
+ <literal>file:/</literal>, <literal>man:</literal> or <literal>info:</literal> URL.</para>
+ </listitem>
+ </varlistentry>
</variablelist>
</refsect1>
<term><varname>_SYSTEMD_SLICE=</varname></term>
<term><varname>_SYSTEMD_UNIT=</varname></term>
<term><varname>_SYSTEMD_USER_UNIT=</varname></term>
+ <term><varname>_SYSTEMD_USER_SLICE=</varname></term>
<term><varname>_SYSTEMD_SESSION=</varname></term>
<term><varname>_SYSTEMD_OWNER_UID=</varname></term>
<varlistentry>
<term><varname>_LINE_BREAK=</varname></term>
<listitem>
- <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: indicates that the log message in the
- standard output/error stream was not terminated with a normal newline character (<literal>\n</literal>,
- i.e. ASCII 10). Specifically, when set this field is one of <option>nul</option> (in case the line was
- terminated by a NUL byte), <option>line-max</option> (in case the maximum log line length was reached, as
- configured with <varname>LineMax=</varname> in
- <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>) or
- <option>eof</option> (if this was the last log record of a stream and the stream ended without a final
- newline character). Note that this record is not generated when a normal newline character was used for
- marking the log line end.</para>
+ <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: indicates that the log message
+ in the standard output/error stream was not terminated with a normal newline character
+ (<literal>\n</literal>, i.e. ASCII 10). Specifically, when set this field is one of
+ <option>nul</option> (in case the line was terminated by a NUL byte), <option>line-max</option> (in
+ case the maximum log line length was reached, as configured with <varname>LineMax=</varname> in
+ <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
+ <option>eof</option> (if this was the last log record of a stream and the stream ended without a
+ final newline character), or <option>pid-change</option> (if the process which generated the log
+ output changed in the middle of a line). Note that this record is not generated when a normal
+ newline character was used for marking the log line end.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_NAMESPACE=</varname></term>
+
+ <listitem><para>If this file was written by a <command>systemd-journald</command> instance managing a
+ journal namespace that is not the default, this field contains the namespace identifier. See
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ for details about journal namespaces.</para>
</listitem>
</varlistentry>
</variablelist>
structured log entries via calls such as
<citerefentry><refentrytitle>sd_journal_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
They may also not be used as matches for
- <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry></para>
+ <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+ </para>
<variablelist class='journal-directives'>
<varlistentry>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,