<title>Description</title>
<para>Entries in the journal resemble an environment
- block in their syntax, however with fields that can
+ block in their syntax but with fields that can
include binary data. Primarily, fields are formatted
UTF-8 text strings, and binary formatting 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
meaning. All fields with special meanings are
- optional. In some cases fields may appear more than
+ optional. In some cases, fields may appear more than
once per entry.</para>
</refsect1>
<term><varname>_UID=</varname></term>
<term><varname>_GID=</varname></term>
<listitem>
- <para>The process, user and
+ <para>The process, user, and
group ID of the process the
journal entry originates from
formatted as a decimal
<term><varname>_CMDLINE=</varname></term>
<listitem>
<para>The name, the executable
- path and the command line of
+ 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><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> of
the process the journal entry
originates from.</para>
</listitem>
<term><varname>_SYSTEMD_UNIT=</varname></term>
<term><varname>_SYSTEMD_USER_UNIT=</varname></term>
<term><varname>_SYSTEMD_OWNER_UID=</varname></term>
+ <term><varname>_SYSTEMD_SLICE=</varname></term>
<listitem>
- <para>The control group path in
- the systemd hierarchy, the
+ <para>The control group path
+ in the systemd hierarchy, the
systemd session ID (if any),
- the systemd unit name (if any),
- the systemd user session unit name (if any)
- and the owner UID of the
- systemd session (if any) of
- the process the journal entry
- originates from.</para>
+ the systemd unit name (if
+ any), the systemd user session
+ unit name (if any), the owner
+ UID of the systemd session (if
+ any) and the systemd slice
+ unit of the process the
+ journal entry originates
+ from.</para>
</listitem>
</varlistentry>
the major and minor of the
device node, separated by <literal>:</literal>
and prefixed by <literal>b</literal>. Similar
- for character devices, but
+ for character devices but
prefixed by <literal>c</literal>. For network
- devices the interface index,
+ devices, this is the interface index
prefixed by <literal>n</literal>. For all other
- devices <literal>+</literal> followed by the
- subsystem name, followed by
+ devices, this is the subsystem name
+ prefixed by <literal>+</literal>, followed by
<literal>:</literal>, followed by the kernel
device name.</para>
</listitem>
</refsect1>
<refsect1>
- <title>Special Journal Fields</title>
+ <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.
+ coredump kernel helper:
</para>
<variablelist class='journal-directives'>
</listitem>
</varlistentry>
</variablelist>
+
+ <para>Priviledged 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>
url="http://www.freedesktop.org/wiki/Software/systemd/json">Journal
JSON Format</ulink>, the addresses of journal entries
are serialized into fields prefixed with double
- underscores. Note that these aren't proper fields when
+ underscores. Note that these are not proper fields when
stored in the journal but for addressing meta data of
entries. They cannot be written as part of structured
log entries via calls such as
~ianmdlvl / elogind.git / blobdiff