NGINX + uWSGI Connection Reset by Peer

Question

I'm trying to host Bottle Application on NGINX using uWSGI.

Here's my nginx.conf

location /myapp/ {
        include uwsgi_params;
        uwsgi_param X-Real-IP $remote_addr;
        uwsgi_param Host $http_host;
        uwsgi_param UWSGI_SCRIPT myapp;
        uwsgi_pass 127.0.0.1:8080;
    }

I'm running uwsgi as this

uwsgi --enable-threads --socket :8080 --plugin python -- wsgi-file ./myApp/myapp.py

I'm using POST Request. For that using dev Http Client. Which goes infinite when I send the request

http://localhost/myapp

uWSGI server receives the request and prints

[pid: 4683|app: 0|req: 1/1] 127.0.0.1 () {50 vars in 806 bytes} [Thu Oct 25 12:29:36 2012] POST /myapp => generated 737 bytes in 11 msecs (HTTP/1.1 404) 2 headers in 87 bytes (1 switches on core 0)

but in nginx error log

2012/10/25 12:20:16 [error] 4364#0: *11 readv() failed (104: Connection reset by peer) while reading upstream, client: 127.0.0.1, server: localhost, request: "POST /myApp/myapp/ HTTP/1.1", upstream: "uwsgi://127.0.0.1:8080", host: "localhost"

What to do?

Answer 1

make sure to consume your post data in your application

for example if you have a Django/python application

def my_view(request):

    # ensure to read the post data, even if you don't need it
    # without this you get a: failed (104: Connection reset by peer)
    data = request.DATA

    return HttpResponse("Hello World")

Some details: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html

Answer 2

You cannot post data from the client without reading it in your application. while this is not a problem in uWSGI, nginx will fail. You can 'fake' the thing using the --post-buffering option of uWSGI to automatically read datas from the socket (if available), but you'd better to "fix" (even if i do not consider that a bug) your app

Answer 3

This problem occurs when the body of a request is not consumed, since uwsgi cannot know whether it will still be needed at some point. So uwsgi will keep holding on to the data either until it is consumed or until nginx resets the connection (because upstream timed out).

The author of uwsgi explains it here:

08:21 < unbit> plaes: does your DELETE request (not-response) have a body ?
08:40 < unbit> and do you read that body in your app ?
08:41 < unbit> from the nginx logs it looks like it has a body and you are not reading it in the app
08:43 < plaes> so DELETE request shouldn't have the body?
08:43 < unbit> no i mean if a request has a body you have to read/consume it
08:44 < unbit> otherwise the socket will be clobbered

So to fix this you need to make sure to always either read the whole request body or not to send a body if it is not necessary (for a DELETE e.g.).

Answer 4

Not use threads!

I have same problem with Global Interpretator Lock in Python under uwsgi. When i don't use threads- not connection reset.

Example of uwsgi config ( 1Gb Ram on server)

[root@mail uwsgi]# cat myproj_config.yaml 
uwsgi:
    print: Myproject Configuration Started
    socket: /var/tmp/myproject_uwsgi.sock
    pythonpath: /sites/myproject/myproj
    env: DJANGO_SETTINGS_MODULE=settings
    module: wsgi
    chdir: /sites/myproject/myproj
    daemonize: /sites/myproject/log/uwsgi.log
    max-requests: 4000
    buffer-size: 32768
    harakiri: 30
    harakiri-verbose: true
    reload-mercy: 8
    vacuum: true
    master: 1
    post-buffering: 8192
    processes: 4
    no-orphans: 1
    touch-reload: /sites/myproject/log/uwsgi
    post-buffering: 8192