]> git.ipfire.org Git - thirdparty/systemd.git/blobdiff - man/systemd.journal-fields.xml
test/test-functions: avoid stderr noise, only umount on cleanup if mountpoint
[thirdparty/systemd.git] / man / systemd.journal-fields.xml
index c079274c324d0409cba16c960f33113845555d57..fa374bf0f804d1cdc487a8fed111cd00e5c9e274 100644 (file)
@@ -1,10 +1,7 @@
 <?xml version='1.0'?> <!--*-nxml-*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<!--
-  SPDX-License-Identifier: LGPL-2.1+
--->
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
 
 <refentry id="systemd.journal-fields">
 
       <varlistentry>
         <term><varname>MESSAGE_ID=</varname></term>
         <listitem>
-          <para>A 128-bit message identifier ID for recognizing
-          certain message types, if this is desirable. This should
-          contain a 128-bit ID formatted as a lower-case hexadecimal
-          string, without any separating dashes or suchlike. This is
-          recommended to be a UUID-compatible ID, but this is not
-          enforced, and formatted differently. Developers can generate
-          a new ID for this purpose with <command>journalctl
-          <option>--new-id128</option></command>.
+          <para>A 128-bit message identifier ID for recognizing certain message types, if this is desirable. This
+          should contain a 128-bit ID formatted as a lower-case hexadecimal string, without any separating dashes or
+          suchlike. This is recommended to be a UUID-compatible ID, but this is not enforced, and formatted
+          differently. Developers can generate a new ID for this purpose with <command>systemd-id128 new</command>.
           </para>
         </listitem>
       </varlistentry>
         <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"), and the client PID. (Note that the tag is usually
-          derived from glibc's
-          <varname>program_invocation_short_name</varname> variable,
-          see
+          <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>
     </variablelist>
   </refsect1>