From 1f15ce28461ec54f85908efc063f99dc5a65b4ca Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Thu, 5 May 2016 13:39:31 +0200 Subject: [PATCH] core: change default trigger limits for socket units Let's lower the default values a bit, and pick different defaults for Accept=yes and Accept=no sockets. Fixes: #3167 --- man/systemd.socket.xml | 13 +++++++------ src/core/socket.c | 22 +++++++++++++++++++++- 2 files changed, 28 insertions(+), 7 deletions(-) diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml index 735268c..5bf54d8 100644 --- a/man/systemd.socket.xml +++ b/man/systemd.socket.xml @@ -814,13 +814,14 @@ Configures a limit on how often this socket unit my be activated within a specific time interval. The TriggerLimitIntervalSec= may be used to configure the length of the time interval in the usual time units us, ms, s, - min, h, … and defaults to 5s (See + min, h, … and defaults to 2s (See systemd.time7 for details on - the various time units available). The TriggerLimitBurst= 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. + the various time units understood). The TriggerLimitBurst= setting takes a positive integer + value and specifies the number of permitted activations per time interval, and defaults to 200 for + Accept=yes sockets (thus by default permitting 200 activations per 2s), and 20 otherwise (20 + activations per 2s). 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. diff --git a/src/core/socket.c b/src/core/socket.c index d3d4866..4fc66af 100644 --- a/src/core/socket.c +++ b/src/core/socket.c @@ -100,7 +100,8 @@ static void socket_init(Unit *u) { s->control_command_id = _SOCKET_EXEC_COMMAND_INVALID; - RATELIMIT_INIT(s->trigger_limit, 5*USEC_PER_SEC, 2500); + s->trigger_limit.interval = USEC_INFINITY; + s->trigger_limit.burst = (unsigned) -1; } static void socket_unwatch_control_pid(Socket *s) { @@ -328,6 +329,25 @@ static int socket_add_extras(Socket *s) { assert(s); + /* Pick defaults for the trigger limit, if nothing was explicitly configured. We pick a relatively high limit + * in Accept=yes mode, and a lower limit for Accept=no. Reason: in Accept=yes mode we are invoking accept() + * ourselves before the trigger limit can hit, thus incoming connections are taken off the socket queue quickly + * and reliably. This is different for Accept=no, where the spawned service has to take the incoming traffic + * off the queues, which it might not necessarily do. Moreover, while Accept=no services are supposed to + * process whatever is queued in one go, and thus should normally never have to be started frequently. This is + * different for Accept=yes where each connection is processed by a new service instance, and thus frequent + * service starts are typical. */ + + if (s->trigger_limit.interval == USEC_INFINITY) + s->trigger_limit.interval = 2 * USEC_PER_SEC; + + if (s->trigger_limit.burst == (unsigned) -1) { + if (s->accept) + s->trigger_limit.burst = 200; + else + s->trigger_limit.burst = 20; + } + if (have_non_accept_socket(s)) { if (!UNIT_DEREF(s->service)) { -- 2.7.4