<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>
messages is generated. This rate
limiting is applied per-service, so
that two services which log do not
- interfere with each other's
- limit. Defaults to 100 messages in
+ interfere with each others'
+ limits. Defaults to 200 messages in
10s. The time specification for
<varname>RateLimitInterval=</varname>
may be specified in the following
<term><varname>SystemMaxUse=</varname></term>
<term><varname>SystemKeepFree=</varname></term>
<term><varname>SystemMaxFileSize=</varname></term>
- <term><varname>SystemMinFileSize=</varname></term>
<term><varname>RuntimeMaxUse=</varname></term>
<term><varname>RuntimeKeepFree=</varname></term>
<term><varname>RuntimeMaxFileSize=</varname></term>
- <term><varname>RuntimeMinFileSize=</varname></term>
<listitem><para>Enforce size limits on
the journal files stored. The options
<varname>SystemMaxUse=</varname> and
<varname>RuntimeMaxUse=</varname>, so
that usually seven rotated journal
- files are kept as
- history. <varname>SystemMinFileSize=</varname>
- and
- <varname>RuntimeMinFileSize=</varname>
- control how large individual journal
- files grow at minimum. Defaults to
- 64K. Specify values in bytes or use
- K, M, G, T, P, E as units for the
- specified sizes. Note that size limits
- are enforced synchronously to journal
+ files are kept as history. Specify
+ values in bytes or use K, M, G, T, P,
+ E as units for the specified
+ sizes. Note that size limits are
+ enforced synchronously to journal
files as they are extended, and need
no explicit rotation step triggered by
time.</para></listitem>
</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 don't 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 year, month,
+ week, day, h, m 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 don't 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 year, month, week, day, h, m
+ to override the default time unit of
+ seconds. </para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>ForwardToSyslog=</varname></term>
<term><varname>ForwardToKMsg=</varname></term>
<filename>/dev/console</filename>.</para></listitem>
</varlistentry>
- <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>
</variablelist>
</refsect1>