journald.conf.d(5)

NAME#

journald.conf, journald.conf.d, [email protected] - Journal service configuration files

SYNOPSIS#

DESCRIPTION#

These files configure various parameters of the systemd journal service, systemd-journald.service(8). See systemd.syntax(7) for a general description of the syntax.

The systemd-journald instance managing the default namespace is configured by /etc/systemd/journald.conf and associated drop-ins. Instances managing other namespaces read /etc/systemd/journald@NAMESPACE.conf and associated drop-ins with the namespace identifier filled in. This allows each namespace to carry a distinct configuration. See systemd-journald.service(8) for details about journal namespaces.

CONFIGURATION DIRECTORIES AND PRECEDENCE#

The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults. The main configuration file is loaded from one of the listed directories in order of priority, only the first file found is used: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/ [1], /usr/lib/systemd/. The vendor version of the file contains commented out entries showing the defaults as a guide to the administrator. Local overrides can also be created by creating drop-ins, as described below. The main configuration file can also be edited for this purpose (or a copy in /etc/ if it is shipped under /usr/), however using drop-ins for local configuration is recommended over modifications to the main configuration file.

In addition to the main configuration file, drop-in configuration snippets are read from /usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/, and /etc/systemd/*.conf.d/. Those drop-ins have higher precedence and override the main configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of in which of the subdirectories they reside. When multiple files specify the same option, for options which accept just a single value, the entry in the file sorted last takes precedence, and for options which accept a list of values, entries are collected as they occur in the sorted files.

When packages need to customize the configuration, they can install drop-ins under /usr/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. Drop-ins have to be used to override package drop-ins, since the main configuration file has lower precedence. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering. This also defines a concept of drop-in priorities to allow OS vendors to ship drop-ins within a specific range lower than the range used by users. This should lower the risk of package drop-ins overriding accidentally drop-ins defined by users. It is recommended to use the range 10-40 for drop-ins in /usr/ and the range 60-90 for drop-ins in /etc/ and /run/, to make sure that local and transient drop-ins take priority over drop-ins shipped by the OS vendor.

To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.

OPTIONS#

All options are configured in the [Journal] section:

Storage=

Note that journald will initially use volatile storage, until a call to journalctl --flush (or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the conditions mentioned above). This is done automatically on boot via "systemd-journal-flush.service".

Note that when this option is changed to "volatile", existing persistent data is not removed. In the other direction, journalctl(1) with the --flush option may be used to move volatile data to persistent storage.

When journal namespacing (see LogNamespace= in systemd.exec(5)) is used, setting Storage= to "volatile" or "auto" will not have an effect on the creation of the per-namespace logs directory in /var/log/journal/, as the [email protected] service file by default carries LogsDirectory=. To turn that off, add a unit file drop-in file that sets LogsDirectory= to an empty string.

Note that per-user journal files are not supported unless persistent storage is enabled, thus making journalctl --user unavailable.

The storage to use can also be specified via the "journal.storage" credential. Values configured via configuration files take priority over values configured via the credential.

Added in version 186.

Compress=

Seal=

Added in version 189.

SplitMode=

Added in version 190.

RateLimitIntervalSec=, RateLimitBurst=

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.

Table 1. Example RateLimitBurst= rate modifications by the available disk space

If a service provides rate limits for itself through LogRateLimitIntervalSec= and/or LogRateLimitBurst= in systemd.exec(5), those values will override the settings specified here.

SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles=

SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values.

The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each of the calculated default values is capped to 4G. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the 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 reduce the footprint again, either. Also note that only archived files are deleted to reduce the space occupied by journal files. This means that, in effect, there might still be more space used than SystemMaxUse= or RuntimeMaxUse= limit after a vacuuming operation is complete.

SystemMaxFileSize= and RuntimeMaxFileSize= control how large individual journal files may grow at most. 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 SystemMaxUse= and RuntimeMaxUse= capped to 128M, so that usually seven rotated journal files are kept as history. If the journal compact mode is enabled (enabled by default), the maximum file size is capped to 4G.

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.

SystemMaxFiles= and RuntimeMaxFiles= control how many individual journal files to keep at most. Note that only archived files are deleted to reduce the number of files until this limit is reached; active files will stay around. This means that, in effect, there might still be more journal files around in total than this limit after a vacuuming operation is complete. This setting defaults to 100.

MaxFileSec=

Added in version 195.

MaxRetentionSec=

Added in version 195.

SyncIntervalSec=

Added in version 199.

ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=, ForwardToSocket=

The socket forwarding address can be specified with the credential "journal.forward_to_socket". The following socket types are supported:

AF_INET (e.g. "192.168.0.11:4444"), AF_INET6 (e.g. "[2001:db8::ff00:42:8329]:4444"), AF_UNIX (e.g. "/run/host/journal/socket"), AF_VSOCK (e.g. "vsock:2:1234")

When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below.

When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for the log buffer, for example by adding "log_buf_len=8M" to the kernel command line. systemd will automatically disable kernel's rate-limiting applied to userspace processes (equivalent to setting "printk.devkmsg=on").

When forwarding over a socket the Journal Export Format[4] is used when sending over the wire. Notably this includes the metadata field __REALTIME_TIMESTAMP so that systemd-journal-remote (see systemd-journal-remote.service(8)) can be used to receive the forwarded journal entries.

Note: Forwarding is performed synchronously within journald, and may significantly affect its performance. This is particularly relevant when using ForwardToConsole=yes in cloud environments, where the console is often a slow, virtual serial port. Since journald is implemented as a conventional single-process daemon, forwarding to a completely hung console will block journald. This can have a cascading effect resulting in any services synchronously logging to the blocked journal also becoming blocked. Unless actively debugging/developing something, it is generally preferable to setup a journalctl --follow style service redirected to the console, instead of ForwardToConsole=yes, for production use.

Note: Using ForwardToSocket= over IPv4/IPv6 links can be very slow due to the synchronous nature of the sockets. Take care to ensure your link is a low-latency local link if possible. Typically IP networking is not available everywhere journald runs, e.g. in the initrd during boot. Consider using AF_VSOCK/AF_UNIX sockets for this if possible.

MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=, MaxLevelSocket=

Added in version 185.

ReadKMsg=

Added in version 235.

Audit=

Note that this option does not control whether systemd-journald collects generated audit records, it just controls whether it tells the kernel to generate them. If you need to prevent systemd-journald from collecting the generated messages, the socket unit "systemd-journald-audit.socket" can be disabled and, in this case, this setting is without effect.

Added in version 246.

TTYPath=

Added in version 185.

LineMax=

Added in version 235.

FORWARDING TO TRADITIONAL SYSLOG DAEMONS#

Journal events can be transferred to a different logging daemon in two different ways. With the first method, messages are immediately forwarded to a socket (/run/systemd/journal/syslog), where the traditional syslog daemon can read them. This method is controlled by the ForwardToSyslog= option. With a second method, a syslog daemon behaves like a normal journal client, and reads messages from the journal files, similarly to journalctl(1). With this, 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 Storage=none is set. It should be noted that usually the second method is used by syslog daemons, so the Storage= option, and not the ForwardToSyslog= option, is relevant for them.

SEE ALSO#

systemd(1), systemd-journald.service(8), journalctl(1), systemd.journal-fields(7), systemd-system.conf(5)

NOTES#

1.

💣💥🧨💥💥💣 Please note that those configuration files must be available at all times. If /usr/local/ is a separate partition, it may not be available during early boot, and must not be used for configuration.

2.

Seekable Sequential Key Generators

3.

Users, Groups, UIDs and GIDs on systemd systems

4.

Journal Export Format