"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
<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>
<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>
<itemizedlist>
<listitem><para>Kernel log messages, via kmsg</para></listitem>
- <listitem><para>Simple system log messages, via the libc
- <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ <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 system
- services</para></listitem>
+ <listitem><para>Standard output and standard error of service units. For further details see
+ below.</para></listitem>
- <listitem><para>Audit records, via the audit
- subsystem</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 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>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>
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>
+ <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.</para></listitem>
+ 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>
<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>
+ 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>
<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>.
+ <command>pydoc systemd.journal</command>
</para>
</refsect1>
projects / thirdparty / systemd.git / blobdiff