man/systemd.journal-fields.xml

   1 <?xml version='1.0'?> <!--*-nxml-*-->
   2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
   4 <!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
   5
   6 <refentry id="systemd.journal-fields">
   7
   8   <refentryinfo>
   9     <title>systemd.journal-fields</title>
  10     <productname>systemd</productname>
  11   </refentryinfo>
  12
  13   <refmeta>
  14     <refentrytitle>systemd.journal-fields</refentrytitle>
  15     <manvolnum>7</manvolnum>
  16   </refmeta>
  17
  18   <refnamediv>
  19     <refname>systemd.journal-fields</refname>
  20     <refpurpose>Special journal fields</refpurpose>
  21   </refnamediv>
  22
  23   <refsect1>
  24     <title>Description</title>
  25
  26     <para>Entries in the journal (as written by
  27     <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
  28     resemble a UNIX process environment block in syntax but with field values that may include binary data,
  29     and with non-unique field names permitted. Primarily, field values are formatted UTF-8 text strings —
  30     binary encoding is used only where formatting as UTF-8 text strings makes little sense. New fields may
  31     freely be defined by applications, but a few fields have special meanings, which are listed
  32     below. Typically, fields may only appear once per log entry, however there are special exceptions: some
  33     fields may appear more than once per entry, in which case this is explicitly mentioned below. Even though
  34     the logging subsystem makes no restrictions on which fields to accept non-unique values for, it is
  35     strongly recommended to avoid relying on this for the fields listed below (except where listed otherwise,
  36     as mentioned) in order to avoid unnecessary incompatibilities with other applications.</para>
  37   </refsect1>
  38
  39   <refsect1>
  40     <title>User Journal Fields</title>
  41
  42     <para>User fields are fields that are directly passed from clients
  43     and stored in the journal.</para>
  44
  45     <variablelist class='journal-directives'>
  46       <varlistentry>
  47         <term><varname>MESSAGE=</varname></term>
  48         <listitem>
  49           <para>The human-readable message string for this entry. This is supposed to be the primary text
  50           shown to the user. It is usually not translated (but might be in some cases), and is not supposed
  51           to be parsed for metadata. In order to encode multiple lines in a single log entry, separate them
  52           by newline characters (ASCII code 10), but encode them as a single <varname>MESSAGE=</varname>
  53           field. Do not add multiple values of this field type to the same entry (also see above), as
  54           consuming applications generally do not expect this and are unlikely to show all values in that
  55           case.</para>
  56         </listitem>
  57       </varlistentry>
  58
  59       <varlistentry>
  60         <term><varname>MESSAGE_ID=</varname></term>
  61         <listitem>
  62           <para>A 128-bit message identifier ID for recognizing certain message types, if this is desirable. This
  63           should contain a 128-bit ID formatted as a lower-case hexadecimal string, without any separating dashes or
  64           suchlike. This is recommended to be a UUID-compatible ID, but this is not enforced, and formatted
  65           differently. Developers can generate a new ID for this purpose with <command>systemd-id128 new</command>.
  66           </para>
  67         </listitem>
  68       </varlistentry>
  69
  70       <varlistentry>
  71         <term><varname>PRIORITY=</varname></term>
  72         <listitem>
  73           <para>A priority value between 0 (<literal>emerg</literal>)
  74           and 7 (<literal>debug</literal>) formatted as a decimal
  75           string. This field is compatible with syslog's priority
  76           concept.</para>
  77         </listitem>
  78       </varlistentry>
  79
  80       <varlistentry>
  81         <term><varname>CODE_FILE=</varname></term>
  82         <term><varname>CODE_LINE=</varname></term>
  83         <term><varname>CODE_FUNC=</varname></term>
  84         <listitem>
  85           <para>The code location generating this message, if known.
  86           Contains the source filename, the line number and the
  87           function name.</para>
  88         </listitem>
  89       </varlistentry>
  90
  91       <varlistentry>
  92         <term><varname>ERRNO=</varname></term>
  93         <listitem>
  94           <para>The low-level Unix error number causing this entry, if
  95           any. Contains the numeric value of
  96           <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
  97           formatted as a decimal string.</para>
  98         </listitem>
  99       </varlistentry>
 100
 101       <varlistentry>
 102         <term><varname>INVOCATION_ID=</varname></term>
 103         <term><varname>USER_INVOCATION_ID=</varname></term>
 104         <listitem>
 105           <para>A randomized, unique 128-bit ID identifying each runtime cycle of the unit. This is different from
 106           <varname>_SYSTEMD_INVOCATION_ID</varname> in that it is only used for messages coming from systemd code
 107           (e.g. logs from the system/user manager or from forked processes performing systemd-related setup).</para>
 108         </listitem>
 109       </varlistentry>
 110
 111       <varlistentry>
 112         <term><varname>SYSLOG_FACILITY=</varname></term>
 113         <term><varname>SYSLOG_IDENTIFIER=</varname></term>
 114         <term><varname>SYSLOG_PID=</varname></term>
 115         <term><varname>SYSLOG_TIMESTAMP=</varname></term>
 116         <listitem>
 117           <para>Syslog compatibility fields containing the facility (formatted as
 118           decimal string), the identifier string (i.e.  "tag"), the client PID, and
 119           the timestamp as specified in the original datagram. (Note that the tag is
 120           usually derived from glibc's
 121           <varname>program_invocation_short_name</varname> variable, see
 122           <citerefentry project='die-net'><refentrytitle>program_invocation_short_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.)</para>
 123           <para>Note that the journal service does not validate the values of any structured
 124           journal fields whose name is not prefixed with an underscore, and this includes any
 125           syslog related fields such as these. Hence, applications that supply a facility, PID,
 126           or log level are expected to do so properly formatted, i.e. as numeric integers formatted
 127           as decimal strings.</para>
 128         </listitem>
 129       </varlistentry>
 130
 131       <varlistentry>
 132         <term><varname>SYSLOG_RAW=</varname></term>
 133         <listitem>
 134           <para>The original contents of the syslog line as received in the syslog
 135           datagram. This field is only included if the <varname>MESSAGE=</varname>
 136           field was modified compared to the original payload or the timestamp could
 137           not be located properly and is not included in
 138           <varname>SYSLOG_TIMESTAMP=</varname>. Message truncation occurs when
 139           the message contains leading or trailing whitespace (trailing and leading
 140           whitespace is stripped), or it contains an embedded
 141           <constant>NUL</constant> byte (the <constant>NUL</constant> byte and
 142           anything after it is not included). Thus, the original syslog line is
 143           either stored as <varname>SYSLOG_RAW=</varname> or it can be recreated
 144           based on the stored priority and facility, timestamp, identifier, and the
 145           message payload in <varname>MESSAGE=</varname>.
 146           </para>
 147         </listitem>
 148       </varlistentry>
 149
 150       <varlistentry>
 151         <term><varname>DOCUMENTATION=</varname></term>
 152         <listitem>
 153           <para>A documentation URL with further information about the topic of the log message. Tools such
 154           as <command>journalctl</command> will include a hyperlink to a URL specified this way in their
 155           output. Should be an <literal>http://</literal>, <literal>https://</literal>,
 156           <literal>file:/</literal>, <literal>man:</literal> or <literal>info:</literal> URL.</para>
 157         </listitem>
 158       </varlistentry>
 159
 160       <varlistentry>
 161         <term><varname>TID=</varname></term>
 162         <listitem>
 163           <para>The numeric thread ID (TID) the log message originates from.</para>
 164         </listitem>
 165       </varlistentry>
 166
 167       <varlistentry>
 168         <term><varname>UNIT=</varname></term>
 169         <term><varname>USER_UNIT=</varname></term>
 170         <listitem>
 171           <para>The name of a unit. Used by the system and user managers when logging about specific
 172           units.</para>
 173
 174           <para>When <option>--unit=<replaceable>name</replaceable></option> or
 175           <option>--user-unit=<replaceable>name</replaceable></option> are used with
 176           <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, a
 177           match pattern that includes <literal>UNIT=<replaceable>name</replaceable>.service</literal> or
 178           <literal>USER_UNIT=<replaceable>name</replaceable>.service</literal> will be generated.</para>
 179         </listitem>
 180       </varlistentry>
 181     </variablelist>
 182   </refsect1>
 183
 184   <refsect1>
 185     <title>Trusted Journal Fields</title>
 186
 187     <para>Fields prefixed with an underscore are trusted fields, i.e.
 188     fields that are implicitly added by the journal and cannot be
 189     altered by client code.</para>
 190
 191     <variablelist class='journal-directives'>
 192       <varlistentry>
 193         <term><varname>_PID=</varname></term>
 194         <term><varname>_UID=</varname></term>
 195         <term><varname>_GID=</varname></term>
 196         <listitem>
 197           <para>The process, user, and group ID of the process the
 198           journal entry originates from formatted as a decimal
 199           string. Note that entries obtained via <literal>stdout</literal> or
 200           <literal>stderr</literal> of forked processes will contain credentials valid for a parent
 201           process (that initiated the connection to <command>systemd-journald</command>).</para>
 202         </listitem>
 203       </varlistentry>
 204
 205       <varlistentry>
 206         <term><varname>_COMM=</varname></term>
 207         <term><varname>_EXE=</varname></term>
 208         <term><varname>_CMDLINE=</varname></term>
 209         <listitem>
 210           <para>The name, the executable path, and the command line of
 211           the process the journal entry originates from.</para>
 212         </listitem>
 213       </varlistentry>
 214
 215       <varlistentry>
 216         <term><varname>_CAP_EFFECTIVE=</varname></term>
 217         <listitem>
 218           <para>The effective
 219           <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 220           of the process the journal entry originates from.</para>
 221         </listitem>
 222       </varlistentry>
 223
 224       <varlistentry>
 225         <term><varname>_AUDIT_SESSION=</varname></term>
 226         <term><varname>_AUDIT_LOGINUID=</varname></term>
 227         <listitem>
 228           <para>The session and login UID of the process the journal
 229           entry originates from, as maintained by the kernel audit
 230           subsystem.</para>
 231         </listitem>
 232       </varlistentry>
 233
 234       <varlistentry>
 235         <term><varname>_SYSTEMD_CGROUP=</varname></term>
 236         <term><varname>_SYSTEMD_SLICE=</varname></term>
 237         <term><varname>_SYSTEMD_UNIT=</varname></term>
 238         <term><varname>_SYSTEMD_USER_UNIT=</varname></term>
 239         <term><varname>_SYSTEMD_USER_SLICE=</varname></term>
 240         <term><varname>_SYSTEMD_SESSION=</varname></term>
 241         <term><varname>_SYSTEMD_OWNER_UID=</varname></term>
 242
 243         <listitem>
 244           <para>The control group path in the systemd hierarchy, the systemd slice unit name, the systemd
 245           unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and
 246           the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry
 247           originates from.</para>
 248         </listitem>
 249       </varlistentry>
 250
 251       <varlistentry>
 252         <term><varname>_SELINUX_CONTEXT=</varname></term>
 253         <listitem>
 254           <para>The SELinux security context (label) of the process
 255           the journal entry originates from.</para>
 256         </listitem>
 257       </varlistentry>
 258
 259       <varlistentry>
 260         <term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term>
 261         <listitem>
 262           <para>The earliest trusted timestamp of the message, if any
 263           is known that is different from the reception time of the
 264           journal. This is the time in microseconds since the epoch
 265           UTC, formatted as a decimal string.</para>
 266         </listitem>
 267       </varlistentry>
 268
 269       <varlistentry>
 270         <term><varname>_BOOT_ID=</varname></term>
 271         <listitem>
 272           <para>The kernel boot ID for the boot the message was
 273           generated in, formatted as a 128-bit hexadecimal
 274           string.</para>
 275         </listitem>
 276       </varlistentry>
 277
 278       <varlistentry>
 279         <term><varname>_MACHINE_ID=</varname></term>
 280         <listitem>
 281           <para>The machine ID of the originating host, as available
 282           in
 283           <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
 284         </listitem>
 285       </varlistentry>
 286
 287       <varlistentry>
 288         <term><varname>_SYSTEMD_INVOCATION_ID=</varname></term>
 289         <listitem>
 290           <para>The invocation ID for the runtime cycle of the unit
 291           the message was generated in, as available to processes
 292           of the unit in <varname>$INVOCATION_ID</varname> (see
 293           <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para>
 294         </listitem>
 295       </varlistentry>
 296
 297       <varlistentry>
 298         <term><varname>_HOSTNAME=</varname></term>
 299         <listitem>
 300           <para>The name of the originating host.</para>
 301         </listitem>
 302       </varlistentry>
 303
 304       <varlistentry>
 305         <term><varname>_TRANSPORT=</varname></term>
 306         <listitem>
 307           <para>How the entry was received by the journal service.
 308           Valid transports are:
 309           </para>
 310           <variablelist>
 311             <varlistentry>
 312               <term>
 313                 <option>audit</option>
 314               </term>
 315               <listitem>
 316                 <para>for those read from the kernel audit subsystem
 317                 </para>
 318               </listitem>
 319             </varlistentry>
 320
 321             <varlistentry>
 322               <term>
 323                 <option>driver</option>
 324               </term>
 325               <listitem>
 326                 <para>for internally generated messages
 327                 </para>
 328               </listitem>
 329             </varlistentry>
 330
 331             <varlistentry>
 332               <term>
 333                 <option>syslog</option>
 334               </term>
 335               <listitem>
 336                 <para>for those received via the local syslog socket
 337                 with the syslog protocol
 338                 </para>
 339               </listitem>
 340             </varlistentry>
 341
 342             <varlistentry>
 343               <term>
 344                 <option>journal</option>
 345               </term>
 346               <listitem>
 347                 <para>for those received via the native journal
 348                 protocol
 349                 </para>
 350               </listitem>
 351             </varlistentry>
 352
 353             <varlistentry>
 354               <term>
 355                 <option>stdout</option>
 356               </term>
 357               <listitem>
 358                 <para>for those read from a service's standard output
 359                 or error output
 360                 </para>
 361               </listitem>
 362             </varlistentry>
 363
 364             <varlistentry>
 365               <term>
 366                 <option>kernel</option>
 367               </term>
 368               <listitem>
 369                 <para>for those read from the kernel
 370                 </para>
 371               </listitem>
 372             </varlistentry>
 373           </variablelist>
 374         </listitem>
 375       </varlistentry>
 376       <varlistentry>
 377         <term><varname>_STREAM_ID=</varname></term>
 378         <listitem>
 379           <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: specifies a randomized 128-bit ID assigned
 380           to the stream connection when it was first created. This ID is useful to reconstruct individual log streams
 381           from the log records: all log records carrying the same stream ID originate from the same stream.</para>
 382         </listitem>
 383       </varlistentry>
 384       <varlistentry>
 385         <term><varname>_LINE_BREAK=</varname></term>
 386         <listitem>
 387           <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: indicates that the log message
 388           in the standard output/error stream was not terminated with a normal newline character
 389           (<literal>\n</literal>, i.e. ASCII 10). Specifically, when set this field is one of
 390           <option>nul</option> (in case the line was terminated by a <constant>NUL</constant> byte), <option>line-max</option> (in
 391           case the maximum log line length was reached, as configured with <varname>LineMax=</varname> in
 392           <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
 393           <option>eof</option> (if this was the last log record of a stream and the stream ended without a
 394           final newline character), or <option>pid-change</option> (if the process which generated the log
 395           output changed in the middle of a line). Note that this record is not generated when a normal
 396           newline character was used for marking the log line end.</para>
 397         </listitem>
 398       </varlistentry>
 399       <varlistentry>
 400         <term><varname>_NAMESPACE=</varname></term>
 401
 402         <listitem><para>If this file was written by a <command>systemd-journald</command> instance managing a
 403         journal namespace that is not the default, this field contains the namespace identifier. See
 404         <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 405         for details about journal namespaces.</para>
 406         </listitem>
 407       </varlistentry>
 408       <varlistentry>
 409         <term><varname>_RUNTIME_SCOPE=</varname></term>
 410
 411         <listitem><para>A string field that specifies the runtime scope in which the message was logged. If
 412         <literal>initrd</literal>, the log message was processed while the system was running inside the
 413         initrd. If <literal>system</literal>, the log message was generated after the system switched
 414         execution to the host root filesystem.</para></listitem>
 415       </varlistentry>
 416     </variablelist>
 417   </refsect1>
 418
 419   <refsect1>
 420     <title>Kernel Journal Fields</title>
 421
 422     <para>Kernel fields are fields that are used by messages
 423     originating in the kernel and stored in the journal.</para>
 424
 425     <variablelist class='journal-directives'>
 426       <varlistentry>
 427         <term><varname>_KERNEL_DEVICE=</varname></term>
 428         <listitem>
 429           <para>The kernel device name. If the entry is associated to a block device, contains the major and
 430           minor numbers of the device node, separated by <literal>:</literal> and prefixed by
 431           <literal>b</literal>. Similarly for character devices, but prefixed by <literal>c</literal>. For
 432           network devices, this is the interface index prefixed by <literal>n</literal>. For all other
 433           devices, this is the subsystem name prefixed by <literal>+</literal>, followed by
 434           <literal>:</literal>, followed by the kernel device name.</para>
 435         </listitem>
 436       </varlistentry>
 437       <varlistentry>
 438         <term><varname>_KERNEL_SUBSYSTEM=</varname></term>
 439         <listitem>
 440           <para>The kernel subsystem name.</para>
 441         </listitem>
 442       </varlistentry>
 443       <varlistentry>
 444         <term><varname>_UDEV_SYSNAME=</varname></term>
 445         <listitem>
 446           <para>The kernel device name as it shows up in the device
 447           tree below <filename>/sys/</filename>.</para>
 448         </listitem>
 449       </varlistentry>
 450       <varlistentry>
 451         <term><varname>_UDEV_DEVNODE=</varname></term>
 452         <listitem>
 453           <para>The device node path of this device in
 454           <filename>/dev/</filename>.</para>
 455         </listitem>
 456       </varlistentry>
 457       <varlistentry>
 458         <term><varname>_UDEV_DEVLINK=</varname></term>
 459         <listitem>
 460           <para>Additional symlink names pointing to the device node
 461           in <filename>/dev/</filename>. This field is frequently set
 462           more than once per entry.</para>
 463         </listitem>
 464       </varlistentry>
 465     </variablelist>
 466   </refsect1>
 467
 468   <refsect1>
 469     <title>Fields to log on behalf of a different program</title>
 470
 471     <para>Fields in this section are used by programs to specify that
 472     they are logging on behalf of another program or unit.
 473     </para>
 474
 475     <para>Fields used by the <command>systemd-coredump</command>
 476     coredump kernel helper:
 477     </para>
 478
 479     <variablelist class='journal-directives'>
 480       <varlistentry>
 481         <term><varname>COREDUMP_UNIT=</varname></term>
 482         <term><varname>COREDUMP_USER_UNIT=</varname></term>
 483         <listitem>
 484           <para>Used to annotate messages containing coredumps from
 485           system and session units. See
 486           <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
 487           </para>
 488         </listitem>
 489       </varlistentry>
 490     </variablelist>
 491
 492     <para>Privileged programs (currently UID 0) may attach
 493     <varname>OBJECT_PID=</varname> to a message. This will instruct
 494     <command>systemd-journald</command> to attach additional fields on
 495     behalf of the caller:</para>
 496
 497     <variablelist class='journal-directives'>
 498       <varlistentry>
 499         <term><varname>OBJECT_PID=<replaceable>PID</replaceable></varname></term>
 500         <listitem>
 501           <para>PID of the program that this message pertains to.
 502           </para>
 503         </listitem>
 504       </varlistentry>
 505
 506       <varlistentry>
 507         <term><varname>OBJECT_UID=</varname></term>
 508         <term><varname>OBJECT_GID=</varname></term>
 509         <term><varname>OBJECT_COMM=</varname></term>
 510         <term><varname>OBJECT_EXE=</varname></term>
 511         <term><varname>OBJECT_CMDLINE=</varname></term>
 512         <term><varname>OBJECT_AUDIT_SESSION=</varname></term>
 513         <term><varname>OBJECT_AUDIT_LOGINUID=</varname></term>
 514         <term><varname>OBJECT_SYSTEMD_CGROUP=</varname></term>
 515         <term><varname>OBJECT_SYSTEMD_SESSION=</varname></term>
 516         <term><varname>OBJECT_SYSTEMD_OWNER_UID=</varname></term>
 517         <term><varname>OBJECT_SYSTEMD_UNIT=</varname></term>
 518         <term><varname>OBJECT_SYSTEMD_USER_UNIT=</varname></term>
 519         <listitem>
 520           <para>These are additional fields added automatically by
 521           <command>systemd-journald</command>. Their meaning is the
 522           same as
 523           <varname>_UID=</varname>,
 524           <varname>_GID=</varname>,
 525           <varname>_COMM=</varname>,
 526           <varname>_EXE=</varname>,
 527           <varname>_CMDLINE=</varname>,
 528           <varname>_AUDIT_SESSION=</varname>,
 529           <varname>_AUDIT_LOGINUID=</varname>,
 530           <varname>_SYSTEMD_CGROUP=</varname>,
 531           <varname>_SYSTEMD_SESSION=</varname>,
 532           <varname>_SYSTEMD_UNIT=</varname>,
 533           <varname>_SYSTEMD_USER_UNIT=</varname>, and
 534           <varname>_SYSTEMD_OWNER_UID=</varname>
 535           as described above, except that the process identified by
 536           <replaceable>PID</replaceable> is described, instead of the
 537           process which logged the message.</para>
 538         </listitem>
 539       </varlistentry>
 540     </variablelist>
 541
 542   </refsect1>
 543
 544   <refsect1>
 545     <title>Address Fields</title>
 546
 547     <para>During serialization into external formats, such as the
 548     <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink>
 549     or the
 550     <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format">Journal JSON Format</ulink>,
 551     the addresses of journal entries are
 552     serialized into fields prefixed with double underscores. Note that
 553     these are not proper fields when stored in the journal but for
 554     addressing metadata of entries. They cannot be written as part of
 555     structured log entries via calls such as
 556     <citerefentry><refentrytitle>sd_journal_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
 557     They may also not be used as matches for
 558     <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
 559     </para>
 560
 561     <variablelist class='journal-directives'>
 562       <varlistentry>
 563         <term><varname>__CURSOR=</varname></term>
 564         <listitem>
 565           <para>The cursor for the entry. A cursor is an opaque text
 566           string that uniquely describes the position of an entry in
 567           the journal and is portable across machines, platforms and
 568           journal files.
 569           </para>
 570         </listitem>
 571       </varlistentry>
 572
 573       <varlistentry>
 574         <term><varname>__REALTIME_TIMESTAMP=</varname></term>
 575         <listitem>
 576           <para>The wallclock time
 577           (<constant>CLOCK_REALTIME</constant>) at the point in time
 578           the entry was received by the journal, in microseconds since
 579           the epoch UTC, formatted as a decimal string. This has
 580           different properties from
 581           <literal>_SOURCE_REALTIME_TIMESTAMP=</literal>, as it is
 582           usually a bit later but more likely to be monotonic.
 583           </para>
 584         </listitem>
 585       </varlistentry>
 586
 587       <varlistentry>
 588         <term><varname>__MONOTONIC_TIMESTAMP=</varname></term>
 589         <listitem>
 590           <para>The monotonic time
 591           (<constant>CLOCK_MONOTONIC</constant>) at the point in time
 592           the entry was received by the journal in microseconds,
 593           formatted as a decimal string. To be useful as an address
 594           for the entry, this should be combined with the boot ID in
 595           <literal>_BOOT_ID=</literal>.
 596           </para>
 597         </listitem>
 598       </varlistentry>
 599
 600       <varlistentry>
 601         <term><varname>__SEQNUM=</varname></term>
 602         <term><varname>__SEQNUM_ID=</varname></term>
 603
 604         <listitem><para>The sequence number (and associated sequence number ID) of this journal entry in the
 605         journal file it originates from. See
 606         <citerefentry><refentrytitle>sd_journal_get_seqnum</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 607         for details.</para></listitem>
 608       </varlistentry>
 609     </variablelist>
 610   </refsect1>
 611
 612   <refsect1>
 613       <title>See Also</title>
 614       <para>
 615         <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 616         <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
 617         <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 618         <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 619         <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
 620         <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 621         <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 622       </para>
 623   </refsect1>
 624
 625 </refentry>