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

Hi Enrico,

Thanks for filing #997990 and #997992 for issues in gunicorn. As it
happens, though, I am no longer using the Debian package of gunicorn
and, as such, I wonder if it makes more sense for someone else to take
over maintainership. At the very least, this will ensure that fixes
for these two issues can reliably tested.

Would this new maintainer be, perhaps, you? :)


Regards,

Thank you for the offer. I'm afraid I can't pick it up, as I'm heavily
struggling to look after my own packages as it is.

I concluded that #997992 is not fixable, and I"m redesigning our
tornado-related architecture to move away from gunicorn and towards
something like https://unrouted.io/ops/2017/04/26/multicore-twistd-with-systemd/

As I'm moving away from using gunicorn to run tornado, it's quite
unlikely I'll also be able to test a fix for #997990 besides rerunning
the test cases I attached to the upstream bug.


Enrico