mirror of
https://github.com/systemd/systemd.git
synced 2024-12-25 01:34:28 +03:00
306 lines
16 KiB
XML
306 lines
16 KiB
XML
<?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+ -->
|
|
|
|
<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</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>3</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. 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>
|
|
</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 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>3</manvolnum></citerefentry>,
|
|
<command>pydoc systemd.journal</command>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|