RemoteDisconnected: Remote end closed connection without response #725
Comments
|
@joelwking Thanks for the report. This one seems to be popping up all over the place all of a sudden. |
|
@joelwking I haven't been able to reproduce this locally however I do believe I have a fix for it. Can you please edit the If that doesn't do it can you please test: I'd like confirmation of the fix and which one of the above resolves the issue, I'm hoping the keepalive is enough but before I submit a PR I'd like to know for sure. |
|
Thanks, I will look at this later today or tomorrow morning. |
|
@nniehoff just to be clear, on the running container, I |
|
@joelwking Once you have the file copied out and modified I would restart the entire container but override the config with a docker volume something like: |
|
@nniehoff Using the configuration file below and the following: docker run -v /home/ubuntu/uwsgi.ini:/opt/nautobot/uwsgi.ini:ro -itd --name nautobot2 -p 8002:8000 nautobot-labI was able to execute the playbook over 15 times without encountering any 'RemoteDisconnected' errors. You seem to have addressed the problem! Thank you. [uwsgi]
; The IP address (typically localhost) and port that the WSGI process should listen on
http = 0.0.0.0:8000
; remote end closed connection
http-keepalive = 1
; add-header = Connection: close
; Fail to start if any parameter in the configuration file isn’t explicitly understood by uWSGI
strict = true
; Enable master process to gracefully re-spawn and pre-fork workers
master = true
; Allow Python app-generated threads to run
enable-threads = true
;Try to remove all of the generated file/sockets during shutdown
vacuum = true
; Do not use multiple interpreters, allowing only Nautobot to run
single-interpreter = true
; Shutdown when receiving SIGTERM (default is respawn)
die-on-term = true
; Prevents uWSGI from starting if it is unable load Nautobot (usually due to errors)
need-app = true
; By default, uWSGI has rather verbose logging that can be noisy
disable-logging = true
; Assert that critical 4xx and 5xx errors are still logged
log-4xx = true
log-5xx = true
;
; Advanced settings (disabled by default)
; Customize these for your environment if and only if you need them.
; Ref: https://uwsgi-docs.readthedocs.io/en/latest/Options.html
;
; Number of uWSGI workers to spawn. This should typically be 2n+1, where n is the number of CPU cores present.
; processes = 5
; If using subdirectory hosting e.g. example.com/nautobot, you must uncomment this line. Otherwise you'll get double paths e.g. example.com/nautobot/nautobot/.
; See: https://uwsgi-docs.readthedocs.io/en/latest/Changelog-2.0.11.html#fixpathinfo-routing-action
; route-run = fixpathinfo: |
|
@joelwking Thanks for validating that's super helpful! I'll work on a PR now |
Adding `http-keepalive = 1` resolves the remote disconnects reported in #725.
Environment
Steps to Reproduce
The issue is not related to a specific module, it occurs on any of the Nautobot modules. This is used for example.
Install the Nautobot lab container at
https://github.com/nautobot/nautobot-labCreate input YAML file:
Execute playbook containing task iterating over the VLANs defined.
Expected Behavior
The API request would execute normally.
Observed Behavior
It would appear this issue is related to the Django server closing the connection. Refer to:
The text was updated successfully, but these errors were encountered: