Package: gunicorn Version: 20.1.0-1 Severity: important Hello,
reproducing this on bullseye needs the workaround to #997990 as a prerequisite. I reported this upstream as https://github.com/benoitc/gunicorn/issues/2672 TL;DR: when using --max-requests and the maximum number of requests is reached *twice*, then a server ends even if there are active long-running requests. On a busy production server, this causes hard to reproduce unrealiability and generalized mayhem. I'm reporting the issue so other users may be aware of it. I haven't yet found a workaround, and I'll post it if I get to a decent one. Unfortunately, using Tornado's own multithreaded webserver I haven't yet found a way to make it exit and restart after a set number of requests, which given the kind of code that ends up being run in my use case, is a much needed feature to contain potential memory issues. Enrico -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gunicorn depends on: ii python3 3.9.2-3 ii python3-gunicorn 20.1.0-1 gunicorn recommends no packages. Versions of packages gunicorn suggests: pn python3-pastedeploy <none> ii python3-setproctitle 1.2.1-1+b1 ii python3-tornado 6.1.0-1+b1 -- no debconf information
