<?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+
-
- This file is part of systemd.
-
- Copyright 2010 Lennart Poettering
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-
- systemd is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public License
- along with systemd; If not, see <http://www.gnu.org/licenses/>.
--->
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="systemd.journal-fields">
<refentryinfo>
<title>systemd.journal-fields</title>
<productname>systemd</productname>
-
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>Lennart</firstname>
- <surname>Poettering</surname>
- <email>lennart@poettering.net</email>
- </author>
- </authorgroup>
</refentryinfo>
<refmeta>
<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>
projects / thirdparty / systemd.git / blobdiff