<?xml version='1.0'?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+ "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
<refentry id="systemd-journald.service">
- <refentryinfo>
- <title>systemd-journald.service</title>
- <productname>systemd</productname>
-
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>Lennart</firstname>
- <surname>Poettering</surname>
- <email>lennart@poettering.net</email>
- </author>
- </authorgroup>
- </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</refname>
- <refpurpose>Journal service</refpurpose>
- </refnamediv>
-
- <refsynopsisdiv>
- <para><filename>systemd-journald.service</filename></para>
- <para><filename>systemd-journald.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 the
- kernel, from user processes via the libc
- <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- call, from standard input and standard error of system
- services or via its native API. It 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. All objects stored in the journal can be up
- to 2^64-1 bytes in size.</para>
-
- <para>By default, the journal stores log data in
- <filename>/run/log/journal/</filename>. Since
- <filename>/run/</filename> is volatile, log data is
- lost at reboot. To make the data persistent, it
- is sufficient to create
- <filename>/var/log/journal/</filename> where
- <filename>systemd-journald</filename> will then store
- the data.</para>
-
- <para><filename>systemd-journald</filename> will
- forward all received log messages to the <constant>AF_UNIX</constant>
- <constant>SOCK_DGRAM</constant> socket
- <filename>/run/systemd/journal/syslog</filename>, if it exists, which
- may be used by Unix syslog daemons to process the data
- further.</para>
-
- <para>See
- <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for information about the configuration of this
- service.</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.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>SIGUSR2</term>
-
- <listitem><para>Request immediate
- rotation of the journal
- files.</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>
- </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 her/him to read the journal files.</para>
-
- <para>By default, each logged in user will get her/his
- own set of journal files in
- <filename>/var/log/journal/</filename>. These 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>
- behaviour. 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></listitem>
- </varlistentry>
- </variablelist>
- </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>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <command>pydoc systemd.journal</command>.
- </para>
- </refsect1>
+ <refentryinfo>
+ <title>systemd-journald.service</title>
+ <productname>systemd</productname>
+
+ <authorgroup>
+ <author>
+ <contrib>Developer</contrib>
+ <firstname>Lennart</firstname>
+ <surname>Poettering</surname>
+ <email>lennart@poettering.net</email>
+ </author>
+ </authorgroup>
+ </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</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>/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>4</manvolnum></citerefentry></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^64-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>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><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>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. The
+ <command>journalctl --flush</command> command uses this signal
+ to request flushing of the journal files, and then waits 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. The <command>journalctl --rotate</command> command uses
+ this signal to request journal file
+ rotation.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>SIGRTMIN+1</term>
+
+ <listitem><para>Request that all unwritten log data is written
+ to disk. The <command>journalctl --sync</command> command uses
+ this signal to trigger journal synchronization, and then waits
+ 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>
+ </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 her/him to read
+ the journal files.</para>
+
+ <para>By default, each logged in user will get her/his own set of
+ journal files in <filename>/var/log/journal/</filename>. These
+ 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></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 paths that
+ <command>systemd-journald</command> will listen on that are
+ visible in the file system. In addition to these, journald can
+ listen for audit events using netlink.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </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='die-net'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>4</manvolnum></citerefentry>,
+ <command>pydoc systemd.journal</command>
+ </para>
+ </refsect1>
</refentry>
projects / thirdparty / systemd.git / blobdiff