"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
+ SPDX-License-Identifier: LGPL-2.1+
+
This file is part of systemd.
Copyright 2010 Lennart Poettering
<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>
+ <listitem><para>Controls whether to split up journal files per user, either <literal>uid</literal> or
+ <literal>none</literal>. 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
+ <literal>uid</literal>, all regular users will each get their own journal files, and system users will log to
+ 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. 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 <varname>Storage=</varname> above), only a single
+ journal file is used. Defaults to <literal>uid</literal>.</para></listitem>
</varlistentry>
<varlistentry>
- <term><varname>RateLimitInterval=</varname></term>
+ <term><varname>RateLimitIntervalSec=</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>,
+ interval defined by <varname>RateLimitIntervalSec=</varname>,
more messages than specified in
<varname>RateLimitBurst=</varname> are logged by a service,
all further messages within the interval are dropped until the
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
+ <varname>RateLimitIntervalSec=</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,
rotated journal files are kept as history.</para>
<para>Specify values in bytes or use K, M, G, T, P, E as
- units for the specified sizes (equal to 1024, 1024², ... bytes).
+ 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>
<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>
+ <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>. If the option name is
+ specified without <literal>=</literal> and the following argument, true is
+ assumed. Otherwise, the argument is parsed as a boolean. When forwarding to the
+ console, the TTY to log to can be changed with <varname>TTYPath=</varname>,
+ described below.</para></listitem>
</varlistentry>
<varlistentry>
<literal>notice</literal> for <varname>MaxLevelKMsg=</varname>,
<literal>info</literal> for <varname>MaxLevelConsole=</varname>,
and <literal>emerg</literal> for
- <varname>MaxLevelWall=</varname>.</para></listitem>
+ <varname>MaxLevelWall=</varname>. These settings may be
+ overridden at boot time with the kernel command line options
+ <literal>systemd.journald.max_level_store=</literal>,
+ <literal>systemd.journald.max_level_syslog=</literal>,
+ <literal>systemd.journald.max_level_kmsg=</literal>,
+ <literal>systemd.journald.max_level_console=</literal>,
+ <literal>systemd.journald.max_level_wall=</literal>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ReadKMsg=</varname></term>
+
+ <listitem><para>Takes a boolean value. If enabled (the
+ default), journal reads <filename>/dev/kmsg</filename>
+ messages generated by the kernel.</para></listitem>
</varlistentry>
<varlistentry>
<filename>/dev/console</filename>.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>LineMax=</varname></term>
+
+ <listitem><para>The maximum line length to permit when converting stream logs into record logs. When a systemd
+ unit's standard output/error are connected to the journal via a stream socket, the data read is split into
+ individual log records at newline (<literal>\n</literal>, ASCII 10) and NUL characters. If no such delimiter is
+ read for the specified number of bytes a hard log record boundary is artificially inserted, breaking up overly
+ long lines into multiple log records. Selecting overly large values increases the possible memory usage of the
+ Journal daemon for each stream client, as in the worst case the journal daemon needs to buffer the specified
+ number of bytes in memory before it can flush a new log record to disk. Also note that permitting overly large
+ line maximum line lengths affects compatibility with traditional log protocols as log records might not fit
+ anymore into a single <constant>AF_UNIX</constant> or <constant>AF_INET</constant> datagram. Takes a size in
+ bytes. If the value is suffixed with K, M, G or T, the specified size is parsed as Kilobytes, Megabytes,
+ Gigabytes, or Terabytes (with the base 1024), respectively. Defaults to 48K, which is relatively large but
+ still small enough so that log records likely fit into network datagrams along with extra room for
+ metadata. Note that values below 79 are not accepted and will be bumped to 79.</para></listitem>
+ </varlistentry>
+
</variablelist>
</refsect1>
projects / thirdparty / systemd.git / blobdiff