<varlistentry>
<term><varname>ProtectClock=</varname></term>
- <listitem><para>Takes a boolean argument. If set, writes to the hardware clock or system clock will be denied.
- It is recommended to turn this on for most services that do not need modify the clock. Defaults to off. Enabling
- this option removes <constant>CAP_SYS_TIME</constant> and <constant>CAP_WAKE_ALARM</constant> from the
- capability bounding set for this unit, installs a system call filter to block calls that can set the
- clock, and <varname>DeviceAllow=char-rtc r</varname> is implied. This ensures <filename>/dev/rtc0</filename>,
- <filename>/dev/rtc1</filename>, etc. are made read-only to the service. See
+ <listitem><para>Takes a boolean argument. If set, writes to the hardware clock or system clock will
+ be denied. Defaults to off. Enabling this option removes <constant>CAP_SYS_TIME</constant> and
+ <constant>CAP_WAKE_ALARM</constant> from the capability bounding set for this unit, installs a system
+ call filter to block calls that can set the clock, and <varname>DeviceAllow=char-rtc r</varname> is
+ implied. Note that the system calls are blocked altogether, the filter does not take into account
+ that some of the calls can be used to read the clock state with some parameter combinations.
+ Effectively, <filename>/dev/rtc0</filename>, <filename>/dev/rtc1</filename>, etc. are made read-only
+ to the service. See
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for the details about <varname>DeviceAllow=</varname>. If this setting is on, but the unit
- doesn't have the <constant>CAP_SYS_ADMIN</constant> capability (e.g. services for which
+ for the details about <varname>DeviceAllow=</varname>. If this setting is on, but the unit doesn't
+ have the <constant>CAP_SYS_ADMIN</constant> capability (e.g. services for which
<varname>User=</varname> is set), <varname>NoNewPrivileges=yes</varname> is implied.</para>
+ <para>It is recommended to turn this on for most services that do not need modify the clock or check
+ its state.</para>
+
<xi:include href="system-or-user-ns.xml" xpointer="singular"/></listitem>
</varlistentry>
<term><varname>LogRateLimitIntervalSec=</varname></term>
<term><varname>LogRateLimitBurst=</varname></term>
- <listitem><para>Configures the rate limiting that is applied to log messages generated by this
- unit. If, in the time interval defined by <varname>LogRateLimitIntervalSec=</varname>, more messages
- than specified in <varname>LogRateLimitBurst=</varname> are logged by a service, all further messages
+ <listitem><para>Configures the rate limiting that is applied to log messages generated by this unit.
+ If, in the time interval defined by <varname>LogRateLimitIntervalSec=</varname>, more messages than
+ specified in <varname>LogRateLimitBurst=</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. The time specification for <varname>LogRateLimitIntervalSec=</varname> may be
- specified in the following units: "s", "min", "h", "ms", "us" (see
+ specified in the following units: "s", "min", "h", "ms", "us". See
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
- details). The default settings are set by <varname>RateLimitIntervalSec=</varname> and
+ details. The default settings are set by <varname>RateLimitIntervalSec=</varname> and
<varname>RateLimitBurst=</varname> configured in
- <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note
- that this only applies to log messages that are processed by the logging subsystem, i.e. by
- <filename>systemd-journald.service</filename>. This means, if you connect a service's stderr directly
- to a file via <varname>StandardOutput=file:…</varname> or a similar setting the rate limiting will
- not be applied to messages written that way (but they will be enforced for messages generated via
- <function>syslog()</function> or similar).</para></listitem>
+ <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ Note that this only applies to log messages that are processed by the logging subsystem, i.e. by
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ This means that if you connect a service's stderr directly to a file via
+ <varname>StandardOutput=file:…</varname> or a similar setting, the rate limiting will not be applied
+ to messages written that way (but it will be enforced for messages generated via
+ <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ and similar functions).</para></listitem>
</varlistentry>
<varlistentry>