Gunicorn: Workers restart with --max-requests=0 when --max-requests-jitter is set to nonzero value

[joekohlsdorf]

To reproduce, start gunicorn like this:

gunicorn -w 1 --max-requests=0 --max-requests-jitter=10 -b 0.0.0.0:8000 api:app

Then direct some traffic to it and observe the following log output:

[2019-02-05 20:27:23 +0000] [19] [INFO] Starting gunicorn 19.9.0
[2019-02-05 20:27:23 +0000] [19] [INFO] Listening at: http://0.0.0.0:8000 (19)
[2019-02-05 20:27:23 +0000] [19] [INFO] Using worker: sync
[2019-02-05 20:27:23 +0000] [22] [INFO] Booting worker with pid: 22
[2019-02-05 20:27:37 +0000] [22] [INFO] Autorestarting worker after current request.
[2019-02-05 20:27:37 +0000] [22] [INFO] Worker exiting (pid: 22)
[2019-02-05 20:27:37 +0000] [24] [INFO] Booting worker with pid: 24

I expect that --max-requests-jitter has no effect when --max-requests is set to 0.

[tilgovi]

What is the behavior you're expecting? Normally, max-requests=0 should mean that workers never auto-restart but from your log it looks as though it does.

[benoitc]

This error has been introduced in d4e1bfe5bd7801c160282310875c70cec15b7c07:

The line self.max_requests = cfg.max_requests + jitter or MAXSIZE now self.max_requests = cfg.max_requests + jitter or sys.maxsize since e974f30517261b2bc95cfb2017a8688f367c8bf3 will set self.max_requests to the _jitter_ value.

We should really set self.max_requests only if its setting value is greater than 0.

[benoitc]

@joekohlsdorf the patch above should fix the error but let us know...

[joekohlsdorf]

Thanks, looks good to me.