summaryrefslogtreecommitdiffstats
path: root/man/systemd.journal-fields.xml
diff options
context:
space:
mode:
Diffstat (limited to 'man/systemd.journal-fields.xml')
-rw-r--r--man/systemd.journal-fields.xml608
1 files changed, 608 insertions, 0 deletions
diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml
new file mode 100644
index 0000000..caedb6e
--- /dev/null
+++ b/man/systemd.journal-fields.xml
@@ -0,0 +1,608 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!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-or-later -->
+
+<refentry id="systemd.journal-fields">
+
+ <refentryinfo>
+ <title>systemd.journal-fields</title>
+ <productname>systemd</productname>
+ </refentryinfo>
+
+ <refmeta>
+ <refentrytitle>systemd.journal-fields</refentrytitle>
+ <manvolnum>7</manvolnum>
+ </refmeta>
+
+ <refnamediv>
+ <refname>systemd.journal-fields</refname>
+ <refpurpose>Special journal fields</refpurpose>
+ </refnamediv>
+
+ <refsect1>
+ <title>Description</title>
+
+ <para>Entries in the journal (as written by
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
+ resemble a UNIX process environment block in syntax but with fields that may include binary data.
+ Primarily, fields are formatted UTF-8 text strings, and binary encoding 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 meanings. All fields with special meanings are optional. In some cases, fields may appear
+ more than once per entry.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>User Journal Fields</title>
+
+ <para>User fields are fields that are directly passed from clients
+ and stored in the journal.</para>
+
+ <variablelist class='journal-directives'>
+ <varlistentry>
+ <term><varname>MESSAGE=</varname></term>
+ <listitem>
+ <para>The human-readable message string for this entry. This
+ is supposed to be the primary text shown to the user. It is
+ usually not translated (but might be in some cases), and is
+ not supposed to be parsed for metadata.</para>
+ </listitem>
+ </varlistentry>
+
+ <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>systemd-id128 new</command>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>PRIORITY=</varname></term>
+ <listitem>
+ <para>A priority value between 0 (<literal>emerg</literal>)
+ and 7 (<literal>debug</literal>) formatted as a decimal
+ string. This field is compatible with syslog's priority
+ concept.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>CODE_FILE=</varname></term>
+ <term><varname>CODE_LINE=</varname></term>
+ <term><varname>CODE_FUNC=</varname></term>
+ <listitem>
+ <para>The code location generating this message, if known.
+ Contains the source filename, the line number and the
+ function name.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ERRNO=</varname></term>
+ <listitem>
+ <para>The low-level Unix error number causing this entry, if
+ any. Contains the numeric value of
+ <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ formatted as a decimal string.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>INVOCATION_ID=</varname></term>
+ <term><varname>USER_INVOCATION_ID=</varname></term>
+ <listitem>
+ <para>A randomized, unique 128-bit ID identifying each runtime cycle of the unit. This is different from
+ <varname>_SYSTEMD_INVOCATION_ID</varname> in that it is only used for messages coming from systemd code
+ (e.g. logs from the system/user manager or from forked processes performing systemd-related setup).</para>
+ </listitem>
+ </varlistentry>
+
+ <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"), 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
+ 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>
+
+ <varlistentry>
+ <term><varname>DOCUMENTATION=</varname></term>
+ <listitem>
+ <para>A documentation URL with further information about the topic of the log message. Tools such
+ as <command>journalctl</command> will include a hyperlink to an URL specified this way in their
+ output. Should be an <literal>http://</literal>, <literal>https://</literal>,
+ <literal>file:/</literal>, <literal>man:</literal> or <literal>info:</literal> URL.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>TID=</varname></term>
+ <listitem>
+ <para>The numeric thread ID (TID) the log message originates from.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>UNIT=</varname></term>
+ <term><varname>USER_UNIT=</varname></term>
+ <listitem>
+ <para>The name of a unit. Used by the system and user managers when logging about specific
+ units.</para>
+
+ <para>When <option>--unit=<replaceable>name</replaceable></option> or
+ <option>--user-unit=<replaceable>name</replaceable></option> are used with
+ <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, a
+ match pattern that includes <literal>UNIT=<replaceable>name</replaceable>.service</literal> or
+ <literal>USER_UNIT=<replaceable>name</replaceable>.service</literal> will be generated.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>Trusted Journal Fields</title>
+
+ <para>Fields prefixed with an underscore are trusted fields, i.e.
+ fields that are implicitly added by the journal and cannot be
+ altered by client code.</para>
+
+ <variablelist class='journal-directives'>
+ <varlistentry>
+ <term><varname>_PID=</varname></term>
+ <term><varname>_UID=</varname></term>
+ <term><varname>_GID=</varname></term>
+ <listitem>
+ <para>The process, user, and group ID of the process the
+ journal entry originates from formatted as a decimal
+ string. Note that entries obtained via <literal>stdout</literal> or
+ <literal>stderr</literal> of forked processes will contain credentials valid for a parent
+ process (that initiated the connection to <command>systemd-journald</command>).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_COMM=</varname></term>
+ <term><varname>_EXE=</varname></term>
+ <term><varname>_CMDLINE=</varname></term>
+ <listitem>
+ <para>The name, the executable 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 project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ of the process the journal entry originates from.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_AUDIT_SESSION=</varname></term>
+ <term><varname>_AUDIT_LOGINUID=</varname></term>
+ <listitem>
+ <para>The session and login UID of the process the journal
+ entry originates from, as maintained by the kernel audit
+ subsystem.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_SYSTEMD_CGROUP=</varname></term>
+ <term><varname>_SYSTEMD_SLICE=</varname></term>
+ <term><varname>_SYSTEMD_UNIT=</varname></term>
+ <term><varname>_SYSTEMD_USER_UNIT=</varname></term>
+ <term><varname>_SYSTEMD_USER_SLICE=</varname></term>
+ <term><varname>_SYSTEMD_SESSION=</varname></term>
+ <term><varname>_SYSTEMD_OWNER_UID=</varname></term>
+
+ <listitem>
+ <para>The control group path in the systemd hierarchy, the systemd slice unit name, the systemd
+ unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and
+ the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry
+ originates from.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_SELINUX_CONTEXT=</varname></term>
+ <listitem>
+ <para>The SELinux security context (label) of the process
+ the journal entry originates from.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term>
+ <listitem>
+ <para>The earliest trusted timestamp of the message, if any
+ is known that is different from the reception time of the
+ journal. This is the time in microseconds since the epoch
+ UTC, formatted as a decimal string.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_BOOT_ID=</varname></term>
+ <listitem>
+ <para>The kernel boot ID for the boot the message was
+ generated in, formatted as a 128-bit hexadecimal
+ string.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_MACHINE_ID=</varname></term>
+ <listitem>
+ <para>The machine ID of the originating host, as available
+ in
+ <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_SYSTEMD_INVOCATION_ID=</varname></term>
+ <listitem>
+ <para>The invocation ID for the runtime cycle of the unit
+ the message was generated in, as available to processes
+ of the unit in <varname>$INVOCATION_ID</varname> (see
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_HOSTNAME=</varname></term>
+ <listitem>
+ <para>The name of the originating host.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>_TRANSPORT=</varname></term>
+ <listitem>
+ <para>How the entry was received by the journal service.
+ Valid transports are:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ <option>audit</option>
+ </term>
+ <listitem>
+ <para>for those read from the kernel audit subsystem
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>driver</option>
+ </term>
+ <listitem>
+ <para>for internally generated messages
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>syslog</option>
+ </term>
+ <listitem>
+ <para>for those received via the local syslog socket
+ with the syslog protocol
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>journal</option>
+ </term>
+ <listitem>
+ <para>for those received via the native journal
+ protocol
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>stdout</option>
+ </term>
+ <listitem>
+ <para>for those read from a service's standard output
+ or error output
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>kernel</option>
+ </term>
+ <listitem>
+ <para>for those read from the kernel
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_STREAM_ID=</varname></term>
+ <listitem>
+ <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: specifies a randomized 128bit ID assigned
+ to the stream connection when it was first created. This ID is useful to reconstruct individual log streams
+ from the log records: all log records carrying the same stream ID originate from the same stream.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_LINE_BREAK=</varname></term>
+ <listitem>
+ <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: indicates that the log message
+ in the standard output/error stream was not terminated with a normal newline character
+ (<literal>\n</literal>, i.e. ASCII 10). Specifically, when set this field is one of
+ <option>nul</option> (in case the line was terminated by a <constant>NUL</constant> byte), <option>line-max</option> (in
+ case the maximum log line length was reached, as configured with <varname>LineMax=</varname> in
+ <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
+ <option>eof</option> (if this was the last log record of a stream and the stream ended without a
+ final newline character), or <option>pid-change</option> (if the process which generated the log
+ output changed in the middle of a line). Note that this record is not generated when a normal
+ newline character was used for marking the log line end.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_NAMESPACE=</varname></term>
+
+ <listitem><para>If this file was written by a <command>systemd-journald</command> instance managing a
+ journal namespace that is not the default, this field contains the namespace identifier. See
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ for details about journal namespaces.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_RUNTIME_SCOPE=</varname></term>
+
+ <listitem><para>A string field that specifies the runtime scope in which the message was logged. If
+ <literal>initrd</literal>, the log message was processed while the system was running inside the
+ initrd. If <literal>system</literal>, the log message was generated after the system switched
+ execution to the host root filesystem.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>Kernel Journal Fields</title>
+
+ <para>Kernel fields are fields that are used by messages
+ originating in the kernel and stored in the journal.</para>
+
+ <variablelist class='journal-directives'>
+ <varlistentry>
+ <term><varname>_KERNEL_DEVICE=</varname></term>
+ <listitem>
+ <para>The kernel device name. If the entry is associated to a block device, contains the major and
+ minor numbers of the device node, separated by <literal>:</literal> and prefixed by
+ <literal>b</literal>. Similarly for character devices, but prefixed by <literal>c</literal>. For
+ network devices, this is the interface index prefixed by <literal>n</literal>. For all other
+ devices, this is the subsystem name prefixed by <literal>+</literal>, followed by
+ <literal>:</literal>, followed by the kernel device name.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_KERNEL_SUBSYSTEM=</varname></term>
+ <listitem>
+ <para>The kernel subsystem name.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_UDEV_SYSNAME=</varname></term>
+ <listitem>
+ <para>The kernel device name as it shows up in the device
+ tree below <filename>/sys/</filename>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_UDEV_DEVNODE=</varname></term>
+ <listitem>
+ <para>The device node path of this device in
+ <filename>/dev/</filename>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>_UDEV_DEVLINK=</varname></term>
+ <listitem>
+ <para>Additional symlink names pointing to the device node
+ in <filename>/dev/</filename>. This field is frequently set
+ more than once per entry.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <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:
+ </para>
+
+ <variablelist class='journal-directives'>
+ <varlistentry>
+ <term><varname>COREDUMP_UNIT=</varname></term>
+ <term><varname>COREDUMP_USER_UNIT=</varname></term>
+ <listitem>
+ <para>Used to annotate messages containing coredumps from
+ system and session units. See
+ <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Privileged 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>
+ <title>Address Fields</title>
+
+ <para>During serialization into external formats, such as the
+ <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink>
+ or the
+ <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format">Journal JSON Format</ulink>,
+ the addresses of journal entries are
+ serialized into fields prefixed with double 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 may also not be used as matches for
+ <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+ </para>
+
+ <variablelist class='journal-directives'>
+ <varlistentry>
+ <term><varname>__CURSOR=</varname></term>
+ <listitem>
+ <para>The cursor for the entry. A cursor is an opaque text
+ string that uniquely describes the position of an entry in
+ the journal and is portable across machines, platforms and
+ journal files.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>__REALTIME_TIMESTAMP=</varname></term>
+ <listitem>
+ <para>The wallclock time
+ (<constant>CLOCK_REALTIME</constant>) at the point in time
+ the entry was received by the journal, in microseconds since
+ the epoch UTC, formatted as a decimal string. This has
+ different properties from
+ <literal>_SOURCE_REALTIME_TIMESTAMP=</literal>, as it is
+ usually a bit later but more likely to be monotonic.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>__MONOTONIC_TIMESTAMP=</varname></term>
+ <listitem>
+ <para>The monotonic time
+ (<constant>CLOCK_MONOTONIC</constant>) at the point in time
+ the entry was received by the journal in microseconds,
+ formatted as a decimal string. To be useful as an address
+ for the entry, this should be combined with the boot ID in
+ <literal>_BOOT_ID=</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>See Also</title>
+ <para>
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ </para>
+ </refsect1>
+
+</refentry>