uWSGI randomly resets TCP connections

[marcquark]

I stumbled across this problem when i wanted to "quickly" spin up a toy installation of Netbox at home. Using a slightly modified version of the example playbook for a single-host deployment, Netbox installed fine on Ubuntu 20.04 and it was accessible via browser. Since it was completely empty i figured i'd start out by importing the community device types using this fine tool.
However after a few requests (usually the 2nd or 3rd), the script would always abort with a "connection reset by peer" exception. I tcpdumped the traffic when it happened, and lo and behold, after a simple (and perfectly valid) GET request, the server would just kill the TCP connection without sending an HTTP response. The request was not showing up in requests.log, and there were no errors in application.log. Using uwsgitop i could also not find any signs of crashing workers or resource shortage (one of my first random attempts was to go from 2C / 2 GB RAM to 4C / 4 GB RAM for the VM).

This seems to be a uWSGI problem, i found lots of threads on GitHub and some other forums. The solutions vary wildly, sometimes it was a browser-specific bug, sometimes the author had control over the application and could change how they handled certain things and so on and so forth. So i started playing around with my uwsgi.ini and after some trial-and-error and more googling, i read this part of the uWSGI docs. Finally i arrived at the following combination of uWSGI options that got rid of the problem

http-keepalive=true
http-auto-chunked=true
add-header=Connection: Close

I'd also like to add that i've successfully run Netbox using this playbook productively before, but never encountered that issue. It might have been on Ubuntu 18.04 though, i can't remember that. It could be that there's some bug in recent versions of Netbox that makes uWSGI exhibit this behaviour. Since their recommended application server is gunicorn, i doubt that anybody can be bothered to debug it though.

I'm looking for feedback as to how the role should be adjusted to account for this bug, which apparently doesn't affect everybody. Should the above settings be made the default, just in case? Then again, it's a bit of a whacky solution and most likely implies a performance hit. So it could also be put into the README as a hint.
Is it worth writing a test case? It should be fairly easy to provoke using requests or pynetbox and firing off a few requests against the API.

[tyler-8]

This role already supports custom uwsgi config parameters via netbox_uwsgi_options so I don't know that any changes would be required. But at least this issue is here for documenting a possible work around for those that might experience these errors.

[tyler-8]

Adding...

These settings also depend on how the user has chosen to deploy NetBox. Native HTTP, sockets, what kind of webserver is used (nginx, haproxy, apache) among other options I'm sure. Given that the existing netbox_uwsgi_options parameter exists, and the possible variance of the environment that NetBox is deployed in, I'm not sure it makes sense to try and expand any further.

[marcquark]

I agree. Had missed the netbox_protocol setting previously, that makes the amount of possibilities vast. Since not every environment seems to be affected anyway, changing defaults is probably not the way to go.

Here are my working netbox_uwsgi_options for brevity (and because i can't get the doc to format as i'd like to, so i'll just reference the issue instead)

netbox_uwsgi_options:
  http-keepalive: "true"
  http-auto-chunked: "true"
  add-header: "Connection: Close"