mirror of
https://github.com/systemd/systemd.git
synced 2024-12-12 03:33:44 +08:00
601 lines
25 KiB
XML
601 lines
25 KiB
XML
<?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>
|
|
</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>
|