| <?xml version='1.0'?> <!--*-nxml-*--> |
| <!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-or-later --> |
| |
| <refentry id="systemd.journal-fields"> |
| |
| <refentryinfo> |
| <title>systemd.journal-fields</title> |
| <productname>systemd</productname> |
| </refentryinfo> |
| |
| <refmeta> |
| <refentrytitle>systemd.journal-fields</refentrytitle> |
| <manvolnum>7</manvolnum> |
| </refmeta> |
| |
| <refnamediv> |
| <refname>systemd.journal-fields</refname> |
| <refpurpose>Special journal fields</refpurpose> |
| </refnamediv> |
| |
| <refsect1> |
| <title>Description</title> |
| |
| <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> |
| <title>User Journal Fields</title> |
| |
| <para>User fields are fields that are directly passed from clients |
| and stored in the journal.</para> |
| |
| <variablelist class='journal-directives'> |
| <varlistentry> |
| <term><varname>MESSAGE=</varname></term> |
| <listitem> |
| <para>The human-readable message string for this entry. This |
| is supposed to be the primary text shown to the user. It is |
| usually not translated (but might be in some cases), and is |
| not supposed to be parsed for metadata.</para> |
| </listitem> |
| </varlistentry> |
| |
| <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>systemd-id128 new</command>. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>PRIORITY=</varname></term> |
| <listitem> |
| <para>A priority value between 0 (<literal>emerg</literal>) |
| and 7 (<literal>debug</literal>) formatted as a decimal |
| string. This field is compatible with syslog's priority |
| concept.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>CODE_FILE=</varname></term> |
| <term><varname>CODE_LINE=</varname></term> |
| <term><varname>CODE_FUNC=</varname></term> |
| <listitem> |
| <para>The code location generating this message, if known. |
| Contains the source filename, the line number and the |
| function name.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>ERRNO=</varname></term> |
| <listitem> |
| <para>The low-level Unix error number causing this entry, if |
| any. Contains the numeric value of |
| <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> |
| formatted as a decimal string.</para> |
| </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> |
| <term><varname>SYSLOG_PID=</varname></term> |
| <term><varname>SYSLOG_TIMESTAMP=</varname></term> |
| <listitem> |
| <para>Syslog compatibility fields containing the facility (formatted as |
| decimal string), the identifier string (i.e. "tag"), the client PID, and |
| the timestamp as specified in the original datagram. (Note that the tag is |
| 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> |
| |
| <varlistentry> |
| <term><varname>SYSLOG_RAW=</varname></term> |
| <listitem> |
| <para>The original contents of the syslog line as received in the syslog |
| datagram. This field is only included if the <varname>MESSAGE=</varname> |
| field was modified compared to the original payload or the timestamp could |
| not be located properly and is not included in |
| <varname>SYSLOG_TIMESTAMP=</varname>. Message truncation occurs when when |
| the message contains leading or trailing whitespace (trailing and leading |
| whitespace is stripped), or it contains an embedded |
| <constant>NUL</constant> byte (the <constant>NUL</constant> byte and |
| anything after it is not included). Thus, the original syslog line is |
| either stored as <varname>SYSLOG_RAW=</varname> or it can be recreated |
| based on the stored priority and facility, timestamp, identifier, and the |
| message payload in <varname>MESSAGE=</varname>. |
| </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 an <literal>http://</literal>, <literal>https://</literal>, |
| <literal>file:/</literal>, <literal>man:</literal> or <literal>info:</literal> URL.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>TID=</varname></term> |
| <listitem> |
| <para>The numeric thread ID (TID) the log message originates from.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>UNIT=</varname></term> |
| <term><varname>USER_UNIT=</varname></term> |
| <listitem> |
| <para>The name of a unit. Used by the system and user managers when logging about specific |
| units.</para> |
| |
| <para>When <option>--unit=<replaceable>name</replaceable></option> or |
| <option>--user-unit=<replaceable>name</replaceable></option> are used with |
| <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, a |
| match pattern that includes <literal>UNIT=<replaceable>name</replaceable>.service</literal> or |
| <literal>USER_UNIT=<replaceable>name</replaceable>.service</literal> will be generated.</para> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| </refsect1> |
| |
| <refsect1> |
| <title>Trusted Journal Fields</title> |
| |
| <para>Fields prefixed with an underscore are trusted fields, i.e. |
| fields that are implicitly added by the journal and cannot be |
| altered by client code.</para> |
| |
| <variablelist class='journal-directives'> |
| <varlistentry> |
| <term><varname>_PID=</varname></term> |
| <term><varname>_UID=</varname></term> |
| <term><varname>_GID=</varname></term> |
| <listitem> |
| <para>The process, user, and group ID of the process the |
| journal entry originates from formatted as a decimal |
| string. Note that entries obtained via <literal>stdout</literal> or |
| <literal>stderr</literal> of forked processes will contain credentials valid for a parent |
| process (that initiated the connection to <command>systemd-journald</command>).</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_COMM=</varname></term> |
| <term><varname>_EXE=</varname></term> |
| <term><varname>_CMDLINE=</varname></term> |
| <listitem> |
| <para>The name, the executable path, and the command line of |
| the process the journal entry originates from.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_CAP_EFFECTIVE=</varname></term> |
| <listitem> |
| <para>The effective |
| <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> |
| of the process the journal entry originates from.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_AUDIT_SESSION=</varname></term> |
| <term><varname>_AUDIT_LOGINUID=</varname></term> |
| <listitem> |
| <para>The session and login UID of the process the journal |
| entry originates from, as maintained by the kernel audit |
| subsystem.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_SYSTEMD_CGROUP=</varname></term> |
| <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> |
| |
| <listitem> |
| <para>The control group path in the systemd hierarchy, the systemd slice unit name, the systemd |
| unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and |
| the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry |
| originates from.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_SELINUX_CONTEXT=</varname></term> |
| <listitem> |
| <para>The SELinux security context (label) of the process |
| the journal entry originates from.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term> |
| <listitem> |
| <para>The earliest trusted timestamp of the message, if any |
| is known that is different from the reception time of the |
| journal. This is the time in microseconds since the epoch |
| UTC, formatted as a decimal string.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_BOOT_ID=</varname></term> |
| <listitem> |
| <para>The kernel boot ID for the boot the message was |
| generated in, formatted as a 128-bit hexadecimal |
| string.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_MACHINE_ID=</varname></term> |
| <listitem> |
| <para>The machine ID of the originating host, as available |
| in |
| <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_SYSTEMD_INVOCATION_ID=</varname></term> |
| <listitem> |
| <para>The invocation ID for the runtime cycle of the unit |
| the message was generated in, as available to processes |
| of the unit in <varname>$INVOCATION_ID</varname> (see |
| <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_HOSTNAME=</varname></term> |
| <listitem> |
| <para>The name of the originating host.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>_TRANSPORT=</varname></term> |
| <listitem> |
| <para>How the entry was received by the journal service. |
| Valid transports are: |
| </para> |
| <variablelist> |
| <varlistentry> |
| <term> |
| <option>audit</option> |
| </term> |
| <listitem> |
| <para>for those read from the kernel audit subsystem |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term> |
| <option>driver</option> |
| </term> |
| <listitem> |
| <para>for internally generated messages |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term> |
| <option>syslog</option> |
| </term> |
| <listitem> |
| <para>for those received via the local syslog socket |
| with the syslog protocol |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term> |
| <option>journal</option> |
| </term> |
| <listitem> |
| <para>for those received via the native journal |
| protocol |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term> |
| <option>stdout</option> |
| </term> |
| <listitem> |
| <para>for those read from a service's standard output |
| or error output |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term> |
| <option>kernel</option> |
| </term> |
| <listitem> |
| <para>for those read from the kernel |
| </para> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term><varname>_STREAM_ID=</varname></term> |
| <listitem> |
| <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: specifies a randomized 128bit ID assigned |
| to the stream connection when it was first created. This ID is useful to reconstruct individual log streams |
| from the log records: all log records carrying the same stream ID originate from the same stream.</para> |
| </listitem> |
| </varlistentry> |
| <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 <constant>NUL</constant> 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> |
| </refsect1> |
| |
| <refsect1> |
| <title>Kernel Journal Fields</title> |
| |
| <para>Kernel fields are fields that are used by messages |
| originating in the kernel and stored in the journal.</para> |
| |
| <variablelist class='journal-directives'> |
| <varlistentry> |
| <term><varname>_KERNEL_DEVICE=</varname></term> |
| <listitem> |
| <para>The kernel device name. If the entry is associated to a block device, contains the major and |
| minor numbers of the device node, separated by <literal>:</literal> and prefixed by |
| <literal>b</literal>. Similarly for character devices, but prefixed by <literal>c</literal>. For |
| network devices, this is the interface index prefixed by <literal>n</literal>. For all other |
| devices, this is the subsystem name prefixed by <literal>+</literal>, followed by |
| <literal>:</literal>, followed by the kernel device name.</para> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term><varname>_KERNEL_SUBSYSTEM=</varname></term> |
| <listitem> |
| <para>The kernel subsystem name.</para> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term><varname>_UDEV_SYSNAME=</varname></term> |
| <listitem> |
| <para>The kernel device name as it shows up in the device |
| tree below <filename>/sys/</filename>.</para> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term><varname>_UDEV_DEVNODE=</varname></term> |
| <listitem> |
| <para>The device node path of this device in |
| <filename>/dev/</filename>.</para> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term><varname>_UDEV_DEVLINK=</varname></term> |
| <listitem> |
| <para>Additional symlink names pointing to the device node |
| in <filename>/dev/</filename>. This field is frequently set |
| more than once per entry.</para> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| </refsect1> |
| |
| <refsect1> |
| <title>Fields to log on behalf of a different program</title> |
| |
| <para>Fields in this section are used by programs to specify that |
| they are logging on behalf of another program or unit. |
| </para> |
| |
| <para>Fields used by the <command>systemd-coredump</command> |
| coredump kernel helper: |
| </para> |
| |
| <variablelist class='journal-directives'> |
| <varlistentry> |
| <term><varname>COREDUMP_UNIT=</varname></term> |
| <term><varname>COREDUMP_USER_UNIT=</varname></term> |
| <listitem> |
| <para>Used to annotate messages containing coredumps from |
| system and session units. See |
| <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. |
| </para> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| |
| <para>Privileged programs (currently UID 0) may attach |
| <varname>OBJECT_PID=</varname> to a message. This will instruct |
| <command>systemd-journald</command> to attach additional fields on |
| behalf of the caller:</para> |
| |
| <variablelist class='journal-directives'> |
| <varlistentry> |
| <term><varname>OBJECT_PID=<replaceable>PID</replaceable></varname></term> |
| <listitem> |
| <para>PID of the program that this message pertains to. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>OBJECT_UID=</varname></term> |
| <term><varname>OBJECT_GID=</varname></term> |
| <term><varname>OBJECT_COMM=</varname></term> |
| <term><varname>OBJECT_EXE=</varname></term> |
| <term><varname>OBJECT_CMDLINE=</varname></term> |
| <term><varname>OBJECT_AUDIT_SESSION=</varname></term> |
| <term><varname>OBJECT_AUDIT_LOGINUID=</varname></term> |
| <term><varname>OBJECT_SYSTEMD_CGROUP=</varname></term> |
| <term><varname>OBJECT_SYSTEMD_SESSION=</varname></term> |
| <term><varname>OBJECT_SYSTEMD_OWNER_UID=</varname></term> |
| <term><varname>OBJECT_SYSTEMD_UNIT=</varname></term> |
| <term><varname>OBJECT_SYSTEMD_USER_UNIT=</varname></term> |
| <listitem> |
| <para>These are additional fields added automatically by |
| <command>systemd-journald</command>. Their meaning is the |
| same as |
| <varname>_UID=</varname>, |
| <varname>_GID=</varname>, |
| <varname>_COMM=</varname>, |
| <varname>_EXE=</varname>, |
| <varname>_CMDLINE=</varname>, |
| <varname>_AUDIT_SESSION=</varname>, |
| <varname>_AUDIT_LOGINUID=</varname>, |
| <varname>_SYSTEMD_CGROUP=</varname>, |
| <varname>_SYSTEMD_SESSION=</varname>, |
| <varname>_SYSTEMD_UNIT=</varname>, |
| <varname>_SYSTEMD_USER_UNIT=</varname>, and |
| <varname>_SYSTEMD_OWNER_UID=</varname> |
| as described above, except that the process identified by |
| <replaceable>PID</replaceable> is described, instead of the |
| process which logged the message.</para> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| |
| </refsect1> |
| |
| <refsect1> |
| <title>Address Fields</title> |
| |
| <para>During serialization into external formats, such as the |
| <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink> |
| or the |
| <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format">Journal JSON Format</ulink>, |
| the addresses of journal entries are |
| serialized into fields prefixed with double underscores. Note that |
| these are not proper fields when stored in the journal but for |
| addressing metadata of entries. They cannot be written as part of |
| 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> |
| |
| <variablelist class='journal-directives'> |
| <varlistentry> |
| <term><varname>__CURSOR=</varname></term> |
| <listitem> |
| <para>The cursor for the entry. A cursor is an opaque text |
| string that uniquely describes the position of an entry in |
| the journal and is portable across machines, platforms and |
| journal files. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>__REALTIME_TIMESTAMP=</varname></term> |
| <listitem> |
| <para>The wallclock time |
| (<constant>CLOCK_REALTIME</constant>) at the point in time |
| the entry was received by the journal, in microseconds since |
| the epoch UTC, formatted as a decimal string. This has |
| different properties from |
| <literal>_SOURCE_REALTIME_TIMESTAMP=</literal>, as it is |
| usually a bit later but more likely to be monotonic. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>__MONOTONIC_TIMESTAMP=</varname></term> |
| <listitem> |
| <para>The monotonic time |
| (<constant>CLOCK_MONOTONIC</constant>) at the point in time |
| the entry was received by the journal in microseconds, |
| formatted as a decimal string. To be useful as an address |
| for the entry, this should be combined with the boot ID in |
| <literal>_BOOT_ID=</literal>. |
| </para> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| </refsect1> |
| |
| <refsect1> |
| <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>, |
| <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> |
| </para> |
| </refsect1> |
| |
| </refentry> |
