mirror of
https://github.com/systemd/systemd-stable.git
synced 2024-12-24 21:34:08 +03:00
402 lines
18 KiB
XML
402 lines
18 KiB
XML
<?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" [
|
|
<!ENTITY % entities SYSTEM "custom-entities.ent" >
|
|
%entities;
|
|
]>
|
|
|
|
<!--
|
|
This file is part of systemd.
|
|
|
|
Copyright 2010 Lennart Poettering
|
|
|
|
systemd is free software; you can redistribute it and/or modify it
|
|
under the terms of the GNU Lesser General Public License as published by
|
|
the Free Software Foundation; either version 2.1 of the License, or
|
|
(at your option) any later version.
|
|
|
|
systemd is distributed in the hope that it will be useful, but
|
|
WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
Lesser General Public License for more details.
|
|
|
|
You should have received a copy of the GNU Lesser General Public License
|
|
along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|
-->
|
|
|
|
<refentry id="journald.conf"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
<refentryinfo>
|
|
<title>journald.conf</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>journald.conf</refentrytitle>
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>journald.conf</refname>
|
|
<refname>journald.conf.d</refname>
|
|
<refpurpose>Journal service configuration files</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<para><filename>&pkgsysconfdir;/journald.conf</filename></para>
|
|
<para><filename>&pkgsysconfdir;/journald.conf.d/*.conf</filename></para>
|
|
<para><filename>/run/systemd/journald.conf.d/*.conf</filename></para>
|
|
<para><filename>&rootlibexecdir;/journald.conf.d/*.conf</filename></para>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>These files configure various parameters of the systemd
|
|
journal service,
|
|
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
|
|
|
</refsect1>
|
|
|
|
<xi:include href="standard-conf.xml" xpointer="main-conf" />
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
|
|
<para>All options are configured in the
|
|
<literal>[Journal]</literal> section:</para>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><varname>Storage=</varname></term>
|
|
|
|
<listitem><para>Controls where to store journal data. One of
|
|
<literal>volatile</literal>,
|
|
<literal>persistent</literal>,
|
|
<literal>auto</literal> and
|
|
<literal>none</literal>. If
|
|
<literal>volatile</literal>, journal
|
|
log data will be stored only in memory, i.e. below the
|
|
<filename>/run/log/journal</filename> hierarchy (which is
|
|
created if needed). If <literal>persistent</literal>, data
|
|
will be stored preferably on disk, i.e. below the
|
|
<filename>/var/log/journal</filename> hierarchy (which is
|
|
created if needed), with a fallback to
|
|
<filename>/run/log/journal</filename> (which is created if
|
|
needed), during early boot and if the disk is not writable.
|
|
<literal>auto</literal> is similar to
|
|
<literal>persistent</literal> but the directory
|
|
<filename>/var/log/journal</filename> is not created if
|
|
needed, so that its existence controls where log data goes.
|
|
<literal>none</literal> turns off all storage, all log data
|
|
received will be dropped. Forwarding to other targets, such as
|
|
the console, the kernel log buffer, or a syslog socket will
|
|
still work however. Defaults to
|
|
<literal>auto</literal>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Compress=</varname></term>
|
|
|
|
<listitem><para>Takes a boolean value. If enabled (the
|
|
default), data objects that shall be stored in the journal and
|
|
are larger than a certain threshold are compressed before they
|
|
are written to the file system.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>Seal=</varname></term>
|
|
|
|
<listitem><para>Takes a boolean value. If enabled (the
|
|
default), and a sealing key is available (as created by
|
|
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
|
<option>--setup-keys</option> command), Forward Secure Sealing
|
|
(FSS) for all persistent journal files is enabled. FSS is
|
|
based on <ulink
|
|
url="https://eprint.iacr.org/2013/397">Seekable Sequential Key
|
|
Generators</ulink> by G. A. Marson and B. Poettering
|
|
(doi:10.1007/978-3-642-40203-6_7) and may be used to protect
|
|
journal files from unnoticed alteration.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>SplitMode=</varname></term>
|
|
|
|
<listitem><para>Controls whether to split up journal files per
|
|
user. One of <literal>uid</literal>, <literal>login</literal>
|
|
and <literal>none</literal>. If <literal>uid</literal>, all
|
|
users will get each their own journal files regardless of
|
|
whether they possess a login session or not, however system
|
|
users will log into the system journal. If
|
|
<literal>login</literal>, actually logged-in users will get
|
|
each their own journal files, but users without login session
|
|
and system users will log into the system journal. If
|
|
<literal>none</literal>, journal files are not split up by
|
|
user and all messages are instead stored in the single system
|
|
journal. Note that splitting up journal files by user is only
|
|
available for journals stored persistently. If journals are
|
|
stored on volatile storage (see above), only a single journal
|
|
file for all user IDs is kept. Defaults to
|
|
<literal>uid</literal>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>RateLimitInterval=</varname></term>
|
|
<term><varname>RateLimitBurst=</varname></term>
|
|
|
|
<listitem><para>Configures the rate limiting that is applied
|
|
to all messages generated on the system. If, in the time
|
|
interval defined by <varname>RateLimitInterval=</varname>,
|
|
more messages than specified in
|
|
<varname>RateLimitBurst=</varname> are logged by a service,
|
|
all further messages within the interval are dropped until the
|
|
interval is over. A message about the number of dropped
|
|
messages is generated. This rate limiting is applied
|
|
per-service, so that two services which log do not interfere
|
|
with each other's limits. Defaults to 1000 messages in 30s.
|
|
The time specification for
|
|
<varname>RateLimitInterval=</varname> may be specified in the
|
|
following units: <literal>s</literal>, <literal>min</literal>,
|
|
<literal>h</literal>, <literal>ms</literal>,
|
|
<literal>us</literal>. To turn off any kind of rate limiting,
|
|
set either value to 0.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>SystemMaxUse=</varname></term>
|
|
<term><varname>SystemKeepFree=</varname></term>
|
|
<term><varname>SystemMaxFileSize=</varname></term>
|
|
<term><varname>RuntimeMaxUse=</varname></term>
|
|
<term><varname>RuntimeKeepFree=</varname></term>
|
|
<term><varname>RuntimeMaxFileSize=</varname></term>
|
|
|
|
<listitem><para>Enforce size limits on the journal files
|
|
stored. The options prefixed with <literal>System</literal>
|
|
apply to the journal files when stored on a persistent file
|
|
system, more specifically
|
|
<filename>/var/log/journal</filename>. The options prefixed
|
|
with <literal>Runtime</literal> apply to the journal files
|
|
when stored on a volatile in-memory file system, more
|
|
specifically <filename>/run/log/journal</filename>. The former
|
|
is used only when <filename>/var</filename> is mounted,
|
|
writable, and the directory
|
|
<filename>/var/log/journal</filename> exists. Otherwise, only
|
|
the latter applies. Note that this means that during early
|
|
boot and if the administrator disabled persistent logging,
|
|
only the latter options apply, while the former apply if
|
|
persistent logging is enabled and the system is fully booted
|
|
up. <command>journalctl</command> and
|
|
<command>systemd-journald</command> ignore all files with
|
|
names not ending with <literal>.journal</literal> or
|
|
<literal>.journal~</literal>, so only such files, located in
|
|
the appropriate directories, are taken into account when
|
|
calculating current disk usage.
|
|
</para>
|
|
|
|
<para><varname>SystemMaxUse=</varname> and
|
|
<varname>RuntimeMaxUse=</varname> control how much disk space
|
|
the journal may use up at maximum.
|
|
<varname>SystemKeepFree=</varname> and
|
|
<varname>RuntimeKeepFree=</varname> control how much disk
|
|
space systemd-journald shall leave free for other uses.
|
|
<command>systemd-journald</command> will respect both limits
|
|
and use the smaller of the two values.</para>
|
|
|
|
<para>The first pair defaults to 10% and the second to 15% of
|
|
the size of the respective file system. If the file system is
|
|
nearly full and either <varname>SystemKeepFree=</varname> or
|
|
<varname>RuntimeKeepFree=</varname> is violated when
|
|
systemd-journald is started, the value will be raised to
|
|
percentage that is actually free. This means that if there was
|
|
enough free space before and journal files were created, and
|
|
subsequently something else causes the file system to fill up,
|
|
journald will stop using more space, but it will not be
|
|
removing existing files to go reduce footprint either.</para>
|
|
|
|
<para><varname>SystemMaxFileSize=</varname> and
|
|
<varname>RuntimeMaxFileSize=</varname> control how large
|
|
individual journal files may grow at maximum. This influences
|
|
the granularity in which disk space is made available through
|
|
rotation, i.e. deletion of historic data. Defaults to one
|
|
eighth of the values configured with
|
|
<varname>SystemMaxUse=</varname> and
|
|
<varname>RuntimeMaxUse=</varname>, so that usually seven
|
|
rotated journal files are kept as history.</para></listitem>
|
|
|
|
<para>Specify values in bytes or use K, M, G, T, P, E as
|
|
units for the specified sizes (equal to 1024, 1024²,... bytes).
|
|
Note that size limits are enforced synchronously when journal
|
|
files are extended, and no explicit rotation step triggered by
|
|
time is needed.</para>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>MaxFileSec=</varname></term>
|
|
|
|
<listitem><para>The maximum time to store entries in a single
|
|
journal file before rotating to the next one. Normally,
|
|
time-based rotation should not be required as size-based
|
|
rotation with options such as
|
|
<varname>SystemMaxFileSize=</varname> should be sufficient to
|
|
ensure that journal files do not grow without bounds. However,
|
|
to ensure that not too much data is lost at once when old
|
|
journal files are deleted, it might make sense to change this
|
|
value from the default of one month. Set to 0 to turn off this
|
|
feature. This setting takes time values which may be suffixed
|
|
with the units <literal>year</literal>,
|
|
<literal>month</literal>, <literal>week</literal>,
|
|
<literal>day</literal>, <literal>h</literal> or
|
|
<literal>m</literal> to override the default time unit of
|
|
seconds.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>MaxRetentionSec=</varname></term>
|
|
|
|
<listitem><para>The maximum time to store journal entries.
|
|
This controls whether journal files containing entries older
|
|
then the specified time span are deleted. Normally, time-based
|
|
deletion of old journal files should not be required as
|
|
size-based deletion with options such as
|
|
<varname>SystemMaxUse=</varname> should be sufficient to
|
|
ensure that journal files do not grow without bounds. However,
|
|
to enforce data retention policies, it might make sense to
|
|
change this value from the default of 0 (which turns off this
|
|
feature). This setting also takes time values which may be
|
|
suffixed with the units <literal>year</literal>,
|
|
<literal>month</literal>, <literal>week</literal>,
|
|
<literal>day</literal>, <literal>h</literal> or <literal>
|
|
m</literal> to override the default time unit of
|
|
seconds.</para></listitem>
|
|
</varlistentry>
|
|
|
|
|
|
<varlistentry>
|
|
<term><varname>SyncIntervalSec=</varname></term>
|
|
|
|
<listitem><para>The timeout before synchronizing journal files
|
|
to disk. After syncing, journal files are placed in the
|
|
OFFLINE state. Note that syncing is unconditionally done
|
|
immediately after a log message of priority CRIT, ALERT or
|
|
EMERG has been logged. This setting hence applies only to
|
|
messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The
|
|
default timeout is 5 minutes. </para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ForwardToSyslog=</varname></term>
|
|
<term><varname>ForwardToKMsg=</varname></term>
|
|
<term><varname>ForwardToConsole=</varname></term>
|
|
<term><varname>ForwardToWall=</varname></term>
|
|
|
|
<listitem><para>Control whether log messages received by the
|
|
journal daemon shall be forwarded to a traditional syslog
|
|
daemon, to the kernel log buffer (kmsg), to the system
|
|
console, or sent as wall messages to all logged-in users.
|
|
These options take boolean arguments. If forwarding to syslog
|
|
is enabled but nothing reads messages from the socket,
|
|
forwarding to syslog has no effect. By default, only
|
|
forwarding to wall is enabled. These settings may be
|
|
overridden at boot time with the kernel command line options
|
|
<literal>systemd.journald.forward_to_syslog=</literal>,
|
|
<literal>systemd.journald.forward_to_kmsg=</literal>,
|
|
<literal>systemd.journald.forward_to_console=</literal>, and
|
|
<literal>systemd.journald.forward_to_wall=</literal>. When
|
|
forwarding to the console, the TTY to log to can be changed
|
|
with <varname>TTYPath=</varname>, described
|
|
below.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>MaxLevelStore=</varname></term>
|
|
<term><varname>MaxLevelSyslog=</varname></term>
|
|
<term><varname>MaxLevelKMsg=</varname></term>
|
|
<term><varname>MaxLevelConsole=</varname></term>
|
|
<term><varname>MaxLevelWall=</varname></term>
|
|
|
|
<listitem><para>Controls the maximum log level of messages
|
|
that are stored on disk, forwarded to syslog, kmsg, the
|
|
console or wall (if that is enabled, see above). As argument,
|
|
takes one of
|
|
<literal>emerg</literal>,
|
|
<literal>alert</literal>,
|
|
<literal>crit</literal>,
|
|
<literal>err</literal>,
|
|
<literal>warning</literal>,
|
|
<literal>notice</literal>,
|
|
<literal>info</literal>,
|
|
<literal>debug</literal>,
|
|
or integer values in the range of 0..7 (corresponding to the
|
|
same levels). Messages equal or below the log level specified
|
|
are stored/forwarded, messages above are dropped. Defaults to
|
|
<literal>debug</literal> for <varname>MaxLevelStore=</varname>
|
|
and <varname>MaxLevelSyslog=</varname>, to ensure that the all
|
|
messages are written to disk and forwarded to syslog. Defaults
|
|
to
|
|
<literal>notice</literal> for <varname>MaxLevelKMsg=</varname>,
|
|
<literal>info</literal> for <varname>MaxLevelConsole=</varname>,
|
|
and <literal>emerg</literal> for
|
|
<varname>MaxLevelWall=</varname>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>TTYPath=</varname></term>
|
|
|
|
<listitem><para>Change the console TTY to use if
|
|
<varname>ForwardToConsole=yes</varname> is used. Defaults to
|
|
<filename>/dev/console</filename>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Forwarding to traditional syslog daemons</title>
|
|
|
|
<para>
|
|
Journal events can be transferred to a different logging daemon
|
|
in two different ways. In the first method, messages are
|
|
immediately forwarded to a socket
|
|
(<filename>/run/systemd/journal/syslog</filename>), where the
|
|
traditional syslog daemon can read them. This method is
|
|
controlled by <varname>ForwardToSyslog=</varname> option. In a
|
|
second method, a syslog daemon behaves like a normal journal
|
|
client, and reads messages from the journal files, similarly to
|
|
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
|
In this method, messages do not have to be read immediately,
|
|
which allows a logging daemon which is only started late in boot
|
|
to access all messages since the start of the system. In
|
|
addition, full structured meta-data is available to it. This
|
|
method of course is available only if the messages are stored in
|
|
a journal file at all. So it will not work if
|
|
<varname>Storage=none</varname> is set. It should be noted that
|
|
usually the <emphasis>second</emphasis> method is used by syslog
|
|
daemons, so the <varname>Storage=</varname> option, and not the
|
|
<varname>ForwardToSyslog=</varname> option, is relevant for them.
|
|
</para>
|
|
</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>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|