<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>
(formatted as decimal string),
the identifier string
(i.e. "tag"), and the client
- PID.</para>
+ PID. (Note that the tag is
+ usually derived from glibc's
+ <varname>program_invocation_short_name</varname>
+ variable, see <citerefentry><refentrytitle>program_invocation_short_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.)</para>
</listitem>
</varlistentry>
<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>
<term><varname>_SELINUX_CONTEXT=</varname></term>
<listitem>
<para>The SELinux security
- context of the process the
- journal entry originates
+ context (label) 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
- stored in the journal but for addressing meta data of
+ 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
~ianmdlvl / elogind.git / blobdiff