Merge pull request #3148 from poettering/trigger

core: introduce activation rate limit and parse nice levels and close sockets properly

5 files changed, 46 insertions, 33 deletions

diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index a9690e8138..3964cd6bc5 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -148,12 +148,12 @@
       </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
@@ -162,7 +162,7 @@
         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,
diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml
index edc6df914a..8833e73c72 100644
--- a/man/systemd-system.conf.xml
+++ b/man/systemd-system.conf.xml
@@ -271,16 +271,16 @@
       </varlistentry>
 
       <varlistentry>
-        <term><varname>DefaultStartLimitInterval=</varname></term>
+        <term><varname>DefaultStartLimitIntervalSec=</varname></term>
         <term><varname>DefaultStartLimitBurst=</varname></term>
 
         <listitem><para>Configure the default unit start rate
         limiting, as configured per-service by
-        <varname>StartLimitInterval=</varname> and
+        <varname>StartLimitIntervalSec=</varname> and
         <varname>StartLimitBurst=</varname>. See
         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
         for details on the per-service settings.
-        <varname>DefaultStartLimitInterval=</varname> defaults to
+        <varname>DefaultStartLimitIntervalSec=</varname> defaults to
         10s. <varname>DefaultStartLimitBurst=</varname> defaults to
         5.</para></listitem>
       </varlistentry>
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 2d0fb63f1d..2a93760428 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -629,27 +629,23 @@
         <term><varname>LimitNICE=</varname></term>
         <term><varname>LimitRTPRIO=</varname></term>
         <term><varname>LimitRTTIME=</varname></term>
-        <listitem><para>These settings set both soft and hard limits
-        of various resources for executed processes. See
-        <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
-        for details. The resource limit is possible to specify in two formats,
-        <option>value</option> to set soft and hard limits to the same value,
-        or <option>soft:hard</option> to set both limits individually (e.g. LimitAS=4G:16G).
-        Use the string <varname>infinity</varname> to
-        configure no limit on a specific resource. The multiplicative
-        suffixes K (=1024), M (=1024*1024) and so on for G, T, P and E
-        may be used for resource limits measured in bytes
-        (e.g. LimitAS=16G). For the limits referring to time values,
-        the usual time units ms, s, min, h and so on may be used (see
-        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
-        for details). Note that if no time unit is specified for
-        <varname>LimitCPU=</varname> the default unit of seconds is
-        implied, while for <varname>LimitRTTIME=</varname> the default
-        unit of microseconds is implied. Also, note that the effective
-        granularity of the limits might influence their
-        enforcement. For example, time limits specified for
-        <varname>LimitCPU=</varname> will be rounded up implicitly to
-        multiples of 1s.</para>
+        <listitem><para>Set soft and hard limits on various resources for executed processes. See
+        <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> for details on
+        the resource limit concept. Resource limits may be specified in two formats: either as single value to set a
+        specific soft and hard limit to the same value, or as colon-separated pair <option>soft:hard</option> to set
+        both limits individually (e.g. <literal>LimitAS=4G:16G</literal>).  Use the string <varname>infinity</varname>
+        to configure no limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base
+        1024) may be used for resource limits measured in bytes (e.g. LimitAS=16G). For the limits referring to time
+        values, the usual time units ms, s, min, h and so on may be used (see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details). Note that if no time unit is specified for <varname>LimitCPU=</varname> the default unit of seconds
+        is implied, while for <varname>LimitRTTIME=</varname> the default unit of microseconds is implied. Also, note
+        that the effective granularity of the limits might influence their enforcement. For example, time limits
+        specified for <varname>LimitCPU=</varname> will be rounded up implicitly to multiples of 1s. For
+        <varname>LimitNICE=</varname> the value may be specified in two syntaxes: if prefixed with <literal>+</literal>
+        or <literal>-</literal>, the value is understood as regular Linux nice value in the range -20..19. If not
+        prefixed like this the value is understood as raw resource limit parameter in the range 0..40 (with 0 being
+        equivalent to 1).</para>
 
         <para>Note that most process resource limits configured with
         these options are per-process, and processes may fork in order
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 2d6339680b..dc3fee5dfb 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -807,6 +807,22 @@
         suffix.</para></listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><varname>TriggerLimitIntervalSec=</varname></term>
+        <term><varname>TriggerLimitIntervalBurst=</varname></term>
+
+        <listitem><para>Configures a limit on how often this socket unit my be activated within a specific time
+        interval. The <varname>TriggerLimitIntervalSec=</varname> may be used to configure the length of the time
+        interval in the usual time units <literal>us</literal>, <literal>ms</literal>, <literal>s</literal>,
+        <literal>min</literal>, <literal>h</literal>, … and defaults to 5s (See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details on
+        the various time units available). The <varname>TriggerLimitBurst=</varname> setting takes an integer value and
+        specifies the numer of permitted activations per time interval, and defaults to 2500 (thus by default
+        permitting 2500 activations per 5s). Set either to 0 to disable any form of trigger rate limiting. If the limit
+        is hit, the socket unit is placed into a failure mode, and will not be connectible anymore until
+        restarted. Note that this limit is enforced before the service activation is enqueued.</para></listitem>
+      </varlistentry>
+
     </variablelist>
 
     <para>Check
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 7993301167..f4b13a7a77 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -751,14 +751,14 @@
       </varlistentry>
 
       <varlistentry>
-        <term><varname>StartLimitInterval=</varname></term>
+        <term><varname>StartLimitIntervalSec=</varname></term>
         <term><varname>StartLimitBurst=</varname></term>
 
         <listitem><para>Configure unit start rate limiting. By default, units which are started more than 5 times
         within 10 seconds are not permitted to start any more times until the 10 second interval ends. With these two
-        options, this rate limiting may be modified. Use <varname>StartLimitInterval=</varname> to configure the
-        checking interval (defaults to <varname>DefaultStartLimitInterval=</varname> in manager configuration file, set
-        to 0 to disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many
+        options, this rate limiting may be modified. Use <varname>StartLimitIntervalSec=</varname> to configure the
+        checking interval (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file,
+        set to 0 to disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many
         starts per interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager
         configuration file). These configuration options are particularly useful in conjunction with the service
         setting <varname>Restart=</varname> (see
@@ -769,14 +769,15 @@
         manually at a later point, from which point on, the restart logic is again activated. Note that
         <command>systemctl reset-failed</command> will cause the restart rate counter for a service to be flushed,
         which is useful if the administrator wants to manually start a unit and the start limit interferes with
-        that.</para></listitem>
+        that. Note that this rate-limiting is enforced after any unit condition checks are executed, and hence unit
+        activations with failing conditions are not counted by this rate limiting.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term><varname>StartLimitAction=</varname></term>
 
         <listitem><para>Configure the action to take if the rate limit configured with
-        <varname>StartLimitInterval=</varname> and <varname>StartLimitBurst=</varname> is hit. Takes one of
+        <varname>StartLimitIntervalSec=</varname> and <varname>StartLimitBurst=</varname> is hit. Takes one of
         <option>none</option>, <option>reboot</option>, <option>reboot-force</option>,
         <option>reboot-immediate</option>, <option>poweroff</option>, <option>poweroff-force</option> or
         <option>poweroff-immediate</option>. If <option>none</option> is set, hitting the rate limit will trigger no