Amazon Linux 2023 の EC2 インスタンスで systemd-journald のデフォルト設定を確認してみた

JOURNALD.CONF(5)                                                                                journald.conf                                                                                JOURNALD.CONF(5)

NAME
       journald.conf, journald.conf.d, journald@.conf - Journal service configuration files

SYNOPSIS
       /etc/systemd/journald.conf

       /etc/systemd/journald.conf.d/*.conf

       /run/systemd/journald.conf.d/*.conf

       /usr/lib/systemd/journald.conf.d/*.conf

       /etc/systemd/journald@NAMESPACE.conf

       /etc/systemd/journald@NAMESPACE.conf.d/*.conf

       /run/systemd/journald@NAMESPACE.conf.d/*.conf

       /usr/lib/systemd/journald@NAMESPACE.conf.d/*.conf

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. Initially, the main configuration file in /etc/systemd/
       contains commented out entries showing the defaults as a guide to the administrator. Local overrides can be created by editing this file or by creating drop-ins, as described below. 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 of the files.

       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=
           Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy
           (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal
           (which is created if needed), during early boot and if the disk is not writable.  "auto" behaves like "persistent" if the /var/log/journal directory exists, and "volatile" otherwise (the
           existence of the directory controls the storage mode).  "none" 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 "auto" in the default journal namespace, and "persistent" in all others.

           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 systemd-journald@.service service file by default carries LogsDirectory=. To turn that off, add a unit file drop-in file that sets LogsDirectory= to an empty string.

       Compress=
           Can take a boolean value. If enabled (the default), data objects that shall be stored in the journal and are larger than the default threshold of 512 bytes are compressed before they are written
           to the file system. It can also be set to a number of bytes to specify the compression threshold directly. Suffixes like K, M, and G can be used to specify larger units.

       Seal=
           Takes a boolean value. If enabled (the default), and a sealing key is available (as created by journalctl(1)'s --setup-keys command), Forward Secure Sealing (FSS) for all persistent journal
           files is enabled. FSS is based on Seekable Sequential Key Generators[1] 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.

       SplitMode=
           Controls whether to split up journal files per user, either "uid" or "none". 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 "uid", 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 Users, Groups, UIDs and GIDs on systemd systems[2] for more details about UID ranges. If "none", 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 Storage= above), only a single journal file is used.
           Defaults to "uid".

       RateLimitIntervalSec=, RateLimitBurst=
           Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitIntervalSec=, more messages than specified in RateLimitBurst=
           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 10000 messages in 30s. The time specification for RateLimitIntervalSec= may be
           specified in the following units: "s", "min", "h", "ms", "us". To turn off any kind of rate limiting, set either value to 0.

           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
           ┌─────────────────────┬──────────────────┐
           │Available Disk Space │ Burst Multiplier │
           ├─────────────────────┼──────────────────┤
           │<= 1MB               │ 1                │
           ├─────────────────────┼──────────────────┤
           │<= 16MB              │ 2                │
           ├─────────────────────┼──────────────────┤
           │<= 256MB             │ 3                │
           ├─────────────────────┼──────────────────┤
           │<= 4GB               │ 4                │
           ├─────────────────────┼──────────────────┤
           │<= 64GB              │ 5                │
           ├─────────────────────┼──────────────────┤
           │<= 1TB               │ 6                │
           └─────────────────────┴──────────────────┘

(中略)
systemd 252                                                                                                                                                                                  JOURNALD.CONF(5)