<?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;

]>

<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. 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></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 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>