<refnamediv>
<refname>journald.conf</refname>
<refname>journald.conf.d</refname>
+ <refname>journald@.conf</refname>
<refpurpose>Journal service configuration files</refpurpose>
</refnamediv>
<para><filename>/etc/systemd/journald.conf.d/*.conf</filename></para>
<para><filename>/run/systemd/journald.conf.d/*.conf</filename></para>
<para><filename>/usr/lib/systemd/journald.conf.d/*.conf</filename></para>
+ <para><filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename></para>
</refsynopsisdiv>
<refsect1>
<para>These files configure various parameters of the systemd journal service,
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
See
- <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for a general description of the syntax.</para>
+ <para>The <command>systemd-journald</command> instance managing the default namespace is configured by
+ <filename>/etc/systemd/journald.conf</filename> and associated drop-ins. Instances managing other
+ namespaces read <filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename> with
+ the namespace identifier filled in. This allows each namespace to carry a distinct configuration. See
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ for details about journal namespaces.</para>
</refsect1>
<xi:include href="standard-conf.xml" xpointer="main-conf" />
<title>Options</title>
<para>All options are configured in the
- <literal>[Journal]</literal> section:</para>
+ [Journal] section:</para>
<variablelist class='config-directives'>
<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>
+ <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> behaves like <literal>persistent</literal> if the
+ <filename>/var/log/journal</filename> directory exists, and <literal>volatile</literal> otherwise
+ (the existence of the directory controls the storage mode). <literal>none</literal> turns off all
+ storage, all log data received will be dropped (but forwarding to other targets, such as the console,
+ the kernel log buffer, or a syslog socket will still work). Defaults to <literal>auto</literal> in
+ the default journal namespace, and <literal>persistent</literal> in all others.</para>
+
+ <para>Note that when this option is changed to <literal>volatile</literal>, existing persistent data
+ is not removed. In the other direction,
+ <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> with
+ the <option>--flush</option> option may be used to move volatile data to persistent storage.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<listitem><para>Controls whether to split up journal files per user, either <literal>uid</literal> or
<literal>none</literal>. Split journal files are primarily useful for access control: on UNIX/Linux access
control is managed per file, and the journal daemon will assign users read access to their journal files. If
- <literal>uid</literal>, all regular users will each get their own journal files, and system users will log to
- the system journal. If <literal>none</literal>, journal files are not split up by user and all messages are
+ <literal>uid</literal>, all regular users (with UID outside the range of system users, dynamic service users,
+ and the nobody user) will each get their own journal files, and system users will log to the system journal.
+ See <ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink>
+ for more details about UID ranges.
+ If <literal>none</literal>, journal files are not split up by user and all messages are
instead stored in the single system journal. In this mode unprivileged users generally do not have access to
their own log data. Note that splitting up journal files by user is only available for journals stored
persistently. If journals are stored on volatile storage (see <varname>Storage=</varname> above), only a single
<literal>us</literal>. To turn off any kind of rate limiting,
set either value to 0.</para>
+ <para>Note that the effective rate limit is multiplied by a
+ factor derived from the available free disk space for the journal.
+ Currently, this factor is calculated using the base 2 logarithm.</para>
+
+ <table>
+ <title>Example <varname>RateLimitBurst=</varname> rate
+ modifications by the available disk space</title>
+ <tgroup cols='2'>
+ <colspec colname='freespace' />
+ <colspec colname='multiplier' />
+ <thead>
+ <row>
+ <entry>Available Disk Space</entry>
+ <entry>Burst Multiplier</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><= 1MB</entry>
+ <entry>1</entry>
+ </row>
+ <row>
+ <entry><= 16MB</entry>
+ <entry>2</entry>
+ </row>
+ <row>
+ <entry><= 256MB</entry>
+ <entry>3</entry>
+ </row>
+ <row>
+ <entry><= 4GB</entry>
+ <entry>4</entry>
+ </row>
+ <row>
+ <entry><= 64GB</entry>
+ <entry>5</entry>
+ </row>
+ <row>
+ <entry><= 1TB</entry>
+ <entry>6</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
<para>If a service provides rate limits for itself through
<varname>LogRateLimitIntervalSec=</varname> and/or <varname>LogRateLimitBurst=</varname>
in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<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>,
+ <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>. If the option name is
- specified without <literal>=</literal> and the following argument, true is
- assumed. Otherwise, the argument is parsed as a boolean. When forwarding to the
- console, the TTY to log to can be changed with <varname>TTYPath=</varname>,
- described below.</para></listitem>
+ <literal>systemd.journald.forward_to_wall</literal>. If the option name is specified without
+ <literal>=</literal> and the following argument, true is assumed. Otherwise, the argument is parsed
+ as a boolean.</para>
+
+ <para>When forwarding to the console, the TTY to log to can be changed with
+ <varname>TTYPath=</varname>, described below.</para>
+
+ <para>When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for
+ the log buffer, for example by adding <literal>log_buf_len=8M</literal> to the kernel command line.
+ <command>systemd</command> will automatically disable kernel's rate-limiting applied to userspace
+ processes (equivalent to setting <literal>printk.devkmsg=on</literal>).</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>MaxLevelWall=</varname></term>
<listitem><para>Controls the maximum log level of messages
- that are stored on disk, forwarded to syslog, kmsg, the
+ that are stored in the journal, forwarded to syslog, kmsg, the
console or wall (if that is enabled, see above). As argument,
takes one of
<literal>emerg</literal>,
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
+ messages are stored in the journal 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
<varlistentry>
<term><varname>ReadKMsg=</varname></term>
- <listitem><para>Takes a boolean value. If enabled (the
- default), journal reads <filename>/dev/kmsg</filename>
- messages generated by the kernel.</para></listitem>
+ <listitem><para>Takes a boolean value. If enabled <command>systemd-journal</command> processes
+ <filename>/dev/kmsg</filename> messages generated by the kernel. In the default journal namespace
+ this option is enabled by default, it is disabled in all others.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Audit=</varname></term>
+
+ <listitem><para>Takes a boolean value. If enabled <command>systemd-journal</command> will turn on
+ kernel auditing on start-up. If disabled it will turn it off. If unset it will neither enable nor
+ disable it, leaving the previous state unchanged. Note that this option does not control whether
+ <command>systemd-journald</command> collects generated audit records, it just controls whether it
+ tells the kernel to generate them. This means if another tool turns on auditing even if
+ <command>systemd-journald</command> left it off, it will still collect the generated
+ messages. Defaults to on.</para></listitem>
</varlistentry>
<varlistentry>
projects / thirdparty / systemd.git / blobdiff