diff options
Diffstat (limited to 'man/systemd.journal-fields.xml')
| -rw-r--r-- | man/systemd.journal-fields.xml | 608 |
1 files changed, 608 insertions, 0 deletions
diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml new file mode 100644 index 0000000..caedb6e --- /dev/null +++ b/man/systemd.journal-fields.xml @@ -0,0 +1,608 @@ +<?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 + 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> + <varlistentry> + <term><varname>_RUNTIME_SCOPE=</varname></term> + + <listitem><para>A string field that specifies the runtime scope in which the message was logged. If + <literal>initrd</literal>, the log message was processed while the system was running inside the + initrd. If <literal>system</literal>, the log message was generated after the system switched + execution to the host root filesystem.</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> |