<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 daemon
+ will still work however. Defaults to
+ <literal>auto</literal>.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>Compress=</varname></term>
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.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>SplitMode=</varname></term>
+
+ <listitem><para>Controls whether to
+ split up journal files per user. One
+ of <literal>login</literal>,
+ <literal>uid</literal> and
+ <literal>none</literal>. If
+ <literal>login</literal> each logged
+ in user will get his own journal
+ files, but systemd user IDs will log
+ into the system journal. If
+ <literal>uid</literal> any user ID
+ will get his own journal files
+ regardless whether it belongs to a
+ system service or refers to a real
+ logged in user. If
+ <literal>none</literal> journal files
+ are not split up per-user and all
+ messages are stored in the single
+ system journal. Note that splitting
+ up journal files per-user is only
+ available of journals are 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>login</literal>.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>RateLimitInterval=</varname></term>
<term><varname>RateLimitBurst=</varname></term>
prefixed with
<literal>System</literal> apply to the
journal files when stored on a
- persistant file system, more
+ persistent file system, more
specifically
<filename>/var/log/journal</filename>. The
options prefixed with
exists. Otherwise only the latter
applies. Note that this means that
during early boot and if the
- administrator disabled persistant
+ administrator disabled persistent
logging only the latter options apply,
- while the former apply if persistant
+ while the former apply if persistent
logging is enabled and the system is
fully booted
up. <varname>SystemMaxUse=</varname>
influences the granularity in which
disk space is made available through
rotation, i.e. deletion of historic
- data. Defaults to one eigth of the
+ data. Defaults to one eighth of the
values configured with
<varname>SystemMaxUse=</varname> and
<varname>RuntimeMaxUse=</varname>, so
is running the respective option has
no effect. By default only forwarding
to syslog 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>
+ 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>
and
- <literal>systemd_journald.forward_to_console=</literal>. If
- forwarding to the kernel log buffer and
- <varname>ImportKernel=</varname> is
- enabled at the same time care is taken
- to avoid logging loops. It is safe to
- use these options in combination.
+ <literal>systemd.journald.forward_to_console=</literal>.
</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>MaxLevelStore=</varname></term>
+ <term><varname>MaxLevelSyslog=</varname></term>
+ <term><varname>MaxLevelKMsg=</varname></term>
+ <term><varname>MaxLevelConsole=</varname></term>
+
+ <listitem><para>Controls the maximum
+ log level of messages that are stored
+ on disk, forwarded to syslog, kmsg or
+ the console (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> and
+ <literal>info</literal> for
+ <varname>MaxLevelConsole=</varname>.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>TTYPath=</varname></term>
<filename>/dev/console</filename>.</para></listitem>
</varlistentry>
- <varlistentry>
- <term><varname>ImportKernel=</varname></term>
-
- <listitem><para>Controls whether
- kernel log messages shall be stored in
- the journal. Takes a boolean argument
- and defaults to enabled. Note that
- currently only one userspace service
- can read kernel messages at a time,
- which means that kernel log message
- reading might get corrupted if it
- is enabled in more than one service,
- for example in both the journal and a
- traditional syslog service.
- </para></listitem>
- </varlistentry>
</variablelist>
</refsect1>
~ianmdlvl / elogind.git / blobdiff