Adding upstream version 252.22.upstream/252.22upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 357 insertions, 0 deletions

diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml
new file mode 100644
index 0000000..8fa8644
--- /dev/null
+++ b/man/systemd-journald.service.xml
@@ -0,0 +1,357 @@
+<?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-journald.service">
+
+  <refentryinfo>
+    <title>systemd-journald.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-journald.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-journald.service</refname>
+    <refname>systemd-journald.socket</refname>
+    <refname>systemd-journald-dev-log.socket</refname>
+    <refname>systemd-journald-audit.socket</refname>
+    <refname>systemd-journald@.service</refname>
+    <refname>systemd-journald@.socket</refname>
+    <refname>systemd-journald-varlink@.socket</refname>
+    <refname>systemd-journald</refname>
+    <refpurpose>Journal service</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-journald.service</filename></para>
+    <para><filename>systemd-journald.socket</filename></para>
+    <para><filename>systemd-journald-dev-log.socket</filename></para>
+    <para><filename>systemd-journald-audit.socket</filename></para>
+    <para><filename>systemd-journald@.service</filename></para>
+    <para><filename>systemd-journald@.socket</filename></para>
+    <para><filename>systemd-journald-varlink@.socket</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-journald</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-journald</filename> is a system service
+    that collects and stores logging data. It creates and maintains
+    structured, indexed journals based on logging information that is
+    received from a variety of sources:</para>
+
+    <itemizedlist>
+      <listitem><para>Kernel log messages, via kmsg</para></listitem>
+
+      <listitem><para>Simple system log messages, via the <filename>libc</filename> <citerefentry
+      project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      call</para></listitem>
+
+      <listitem><para>Structured system log messages via the native Journal API, see
+      <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      and <ulink url="https://systemd.io/JOURNAL_NATIVE_PROTOCOL">Native Journal
+      Protocol</ulink></para></listitem>
+
+      <listitem><para>Standard output and standard error of service units. For further details see
+      below.</para></listitem>
+
+      <listitem><para>Audit records, originating from the kernel audit subsystem</para></listitem>
+    </itemizedlist>
+
+    <para>The daemon will implicitly collect numerous metadata fields
+    for each log messages in a secure and unfakeable way. See
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for more information about the collected metadata.
+    </para>
+
+    <para>Log data collected by the journal is primarily text-based but can also include binary data where
+    necessary. Individual fields making up a log record stored in the journal may be up to 2⁶⁴-1 bytes in size.</para>
+
+    <para>The journal service stores log data either persistently below <filename>/var/log/journal</filename> or in a
+    volatile way below <filename>/run/log/journal/</filename> (in the latter case it is lost at reboot). By default, log
+    data is stored persistently if <filename>/var/log/journal/</filename> exists during boot, with an implicit fallback
+    to volatile storage otherwise. Use <varname>Storage=</varname> in
+    <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> to configure
+    where log data is placed, independently of the existence of <filename>/var/log/journal/</filename>.</para>
+
+    <para>Note that journald will initially use volatile storage, until a call to
+    <command>journalctl --flush</command> (or sending <constant>SIGUSR1</constant> to journald) will cause
+    it to switch to persistent logging (under the conditions mentioned above). This is done automatically
+    on boot via <literal>systemd-journal-flush.service</literal>.</para>
+
+    <para>On systems where <filename>/var/log/journal/</filename> does not exist yet but where persistent logging is
+    desired (and the default <filename>journald.conf</filename> is used), it is sufficient to create the directory, and
+    ensure it has the correct access modes and ownership:</para>
+
+    <programlisting>mkdir -p /var/log/journal
+systemd-tmpfiles --create --prefix /var/log/journal</programlisting>
+
+    <para>See
+    <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for information about the configuration of this service.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Stream logging</title>
+
+    <para>The systemd service manager invokes all service processes with standard output and standard error connected
+    to the journal by default. This behaviour may be altered via the
+    <varname>StandardOutput=</varname>/<varname>StandardError=</varname> unit file settings, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details. The
+    journal converts the log byte stream received this way into individual log records, splitting the stream at newline
+    (<literal>\n</literal>, ASCII <constant>10</constant>) and <constant>NUL</constant> bytes.</para>
+
+    <para>If <filename>systemd-journald.service</filename> is stopped, the stream connections associated with all
+    services are terminated. Further writes to those streams by the service will result in <constant>EPIPE</constant>
+    errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error
+    ignore such errors. If the <constant>SIGPIPE</constant> UNIX signal handler is not blocked or turned off, such
+    write attempts will also result in such process signals being generated, see
+    <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    To mitigate this issue, systemd service manager explicitly turns off the <constant>SIGPIPE</constant>
+    signal for all invoked processes by default (this may be changed for each unit individually via the
+    <varname>IgnoreSIGPIPE=</varname> option, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details). After the standard output/standard error streams have been terminated they may not be recovered
+    until the services they are associated with are restarted. Note that during normal operation,
+    <filename>systemd-journald.service</filename> stores copies of the file descriptors for those streams in
+    the service manager. If <filename>systemd-journald.service</filename> is restarted using
+    <command>systemctl restart</command> or equivalent operation instead of a pair of separate
+    <command>systemctl stop</command> and <command>systemctl start</command> commands (or equivalent
+    operations), these stream connections are not terminated and survive the restart. It is thus safe to
+    restart <filename>systemd-journald.service</filename>, but stopping it is not recommended.</para>
+
+    <para>Note that the log record metadata for records transferred via such standard output/error streams reflect the
+    metadata of the peer the stream was originally created for. If the stream connection is passed on to other
+    processes (such as further child processes forked off the main service process), the log records will not reflect
+    their metadata, but will continue to describe the original process. This is different from the other logging
+    transports listed above, which are inherently record based and where the metadata is always associated with the
+    individual record.</para>
+
+    <para>In addition to the implicit standard output/error logging of services, stream logging is also available
+    via the <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry> command
+    line tool.</para>
+
+    <para>Currently, the number of parallel log streams <filename>systemd-journald</filename> will accept is limited to
+    4096. When this limit is reached further log streams may be established but will receive
+    <constant>EPIPE</constant> right from the beginning.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Journal Namespaces</title>
+
+    <para>Journal 'namespaces' are both a mechanism for logically isolating the log stream of projects
+    consisting of one or more services from the rest of the system and a mechanism for improving
+    performance. Multiple journal namespaces may exist simultaneously, each defining its own, independent log
+    stream managed by its own instance of <command>systemd-journald</command>. Namespaces are independent of
+    each other, both in the data store and in the IPC interface. By default only a single 'default' namespace
+    exists, managed by <filename>systemd-journald.service</filename> (and its associated socket
+    units). Additional namespaces are created by starting an instance of the
+    <filename>systemd-journald@.service</filename> service template. The instance name is the namespace
+    identifier, which is a short string used for referencing the journal namespace. Service units may be
+    assigned to a specific journal namespace through the <varname>LogNamespace=</varname> unit file setting,
+    see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details. The <option>--namespace=</option> switch of
+    <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> may be
+    used to view the log stream of a specific namespace. If the switch is not used the log stream of the
+    default namespace is shown, i.e. log data from other namespaces is not visible.</para>
+
+    <para>Services associated with a specific log namespace may log via syslog, the native logging protocol
+    of the journal and via stdout/stderr; the logging from all three transports is associated with the
+    namespace.</para>
+
+    <para>By default only the default namespace will collect kernel and audit log messages.</para>
+
+    <para>The <command>systemd-journald</command> instance of the default namespace is configured through
+    <filename>/etc/systemd/journald.conf</filename> (see below), while the other instances are configured
+    through <filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename>. The journal
+    log data for the default namespace is placed in
+    <filename>/var/log/journal/<replaceable>MACHINE_ID</replaceable></filename> (see below) while the data
+    for the other namespaces is located in
+    <filename>/var/log/journal/<replaceable>MACHINE_ID</replaceable>.<replaceable>NAMESPACE</replaceable></filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Signals</title>
+
+    <variablelist>
+      <varlistentry>
+        <term>SIGUSR1</term>
+
+        <listitem><para>Request that journal data from <filename>/run/</filename> is flushed to
+        <filename>/var/</filename> in order to make it persistent (if this is enabled). This must be used
+        after <filename>/var/</filename> is mounted, as otherwise log data from <filename>/run/</filename> is
+        never flushed to <filename>/var/</filename> regardless of the configuration. Use the
+        <command>journalctl --flush</command> command to request flushing of the journal files, and wait for
+        the operation to complete. See
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>SIGUSR2</term>
+
+        <listitem><para>Request immediate rotation of the journal files. Use the <command>journalctl
+        --rotate</command> command to request journal file rotation, and wait for the operation to
+        complete.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>SIGRTMIN+1</term>
+
+        <listitem><para>Request that all unwritten log data is written to disk. Use the <command>journalctl
+        --sync</command> command to trigger journal synchronization, and wait for the operation to
+        complete.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para>A few configuration parameters from
+    <filename>journald.conf</filename> may be overridden on the kernel
+    command line:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.journald.forward_to_syslog=</varname></term>
+        <term><varname>systemd.journald.forward_to_kmsg=</varname></term>
+        <term><varname>systemd.journald.forward_to_console=</varname></term>
+        <term><varname>systemd.journald.forward_to_wall=</varname></term>
+
+        <listitem><para>Enables/disables forwarding of collected log
+        messages to syslog, the kernel log buffer, the system console
+        or wall.
+        </para>
+
+        <para>See
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for information about these settings.</para>
+        </listitem>
+
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that these kernel command line options are only honoured by the default namespace, see
+    above.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Access Control</title>
+
+    <para>Journal files are, by default, owned and readable by the
+    <literal>systemd-journal</literal> system group but are not
+    writable. Adding a user to this group thus enables them to read
+    the journal files.</para>
+
+    <para>By default, each user, with a UID outside the range of system users,
+    dynamic service users, and the nobody user, will get their own set of
+    journal files in <filename>/var/log/journal/</filename>. See
+    <ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink>
+    for more details about UID ranges. These journal
+    files will not be owned by the user, however, in order to avoid
+    that the user can write to them directly. Instead, file system
+    ACLs are used to ensure the user gets read access only.</para>
+
+    <para>Additional users and groups may be granted access to journal
+    files via file system access control lists (ACL). Distributions
+    and administrators may choose to grant read access to all members
+    of the <literal>wheel</literal> and <literal>adm</literal> system
+    groups with a command such as the following:</para>
+
+    <programlisting># setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/</programlisting>
+
+    <para>Note that this command will update the ACLs both for
+    existing journal files and for future journal files created in the
+    <filename>/var/log/journal/</filename> directory.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/etc/systemd/journald.conf</filename></term>
+
+        <listitem><para>Configure <command>systemd-journald</command> behavior. See
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term>
+        <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term>
+        <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term>
+        <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term>
+
+        <listitem><para><command>systemd-journald</command> writes entries to files in
+        <filename>/run/log/journal/<replaceable>machine-id</replaceable>/</filename>
+        or
+        <filename>/var/log/journal/<replaceable>machine-id</replaceable>/</filename>
+        with the <literal>.journal</literal> suffix. If the daemon is
+        stopped uncleanly, or if the files are found to be corrupted,
+        they are renamed using the <literal>.journal~</literal>
+        suffix, and <command>systemd-journald</command> starts writing
+        to a new file. <filename>/run/</filename> is used when
+        <filename>/var/log/journal</filename> is not available, or
+        when <option>Storage=volatile</option> is set in the
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        configuration file.</para>
+
+        <para>When <filename>systemd-journald</filename> ceases writing to a journal file,
+        it will be renamed to <literal><replaceable>original-name</replaceable>@<replaceable>suffix.journal</replaceable></literal>
+        (or <literal><replaceable>original-name</replaceable>@<replaceable>suffix.journal~</replaceable></literal>).
+        Such files are "archived" and will not be written to any more.</para>
+
+        <para>In general, it is safe to read or copy any journal file (active or archived).
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and the functions in the
+        <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        library should be able to read all entries that have been fully written.</para>
+
+        <para><filename>systemd-journald</filename> will automatically remove the oldest
+        archived journal files to limit disk use. See <varname>SystemMaxUse=</varname>
+        and related settings in
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/dev/kmsg</filename></term>
+        <term><filename>/dev/log</filename></term>
+        <term><filename>/run/systemd/journal/dev-log</filename></term>
+        <term><filename>/run/systemd/journal/socket</filename></term>
+        <term><filename>/run/systemd/journal/stdout</filename></term>
+
+        <listitem><para>Sockets and other file node paths that <command>systemd-journald</command> will
+        listen on and are visible in the file system. In addition to these,
+        <command>systemd-journald</command> can listen for audit events using <citerefentry
+        project='man-pages'><refentrytitle>netlink</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>If journal namespacing is used these paths are slightly altered to include a namespace identifier, see above.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <command>pydoc systemd.journal</command>
+    </para>
+  </refsect1>
+
+</refentry>