I've just now noticed that I'm getting this error in the Nginx log
when accessing the app in maintenance mode:

[error] 3395#0: *1052 readv() failed (104: Connection reset by peer)
while reading upstream, client: 10.36.204.119, server:
stage.example.com, request: "POST /fbcanvas/ HTTP/1.0", upstream:
"uwsgi://unix:///tmp/example.sock:", host: "stage.example.com",
referrer: "http://apps.facebook.com/example_stage/";

I don't know how I missed this before, but it looks like the
connection is being closed before the response is sent. I did a bit of
a Google search and found this post:
http://stackoverflow.com/questions/3970495/nginx-connection-reset-response-from-uwsgi-lost
but none of the solutions listed in there worked for me.

On Thu, Jan 26, 2012 at 5:04 PM, Guy Knights <[email protected]> 
wrote:
> I hope this is the correct way to reply to this message! Apologies if
> I include a lot of extra junk, I wasn't 100% sure how to just respond
> to the specific message. Anyway...
>
> Roberto, please see below for the nginx config for the uWSGI server:
>
> worker_processes  2;
>
> worker_rlimit_nofile    30000;
>
> pid        /var/run/nginx.pid;
>
> events {
>    worker_connections  10240;
>    use epoll;
> }
>
> http {
>    include       mime.types;
>    default_type  application/octet-stream;
>
>    log_format  main  '$http_x_forwarded_for - $remote_user
> [$time_local] "$request" '
>                      '$status $body_bytes_sent "$http_referer" '
>                      '"$http_user_agent $request_time"';
>
>    sendfile        on;
>
>    client_body_timeout 10;
>    client_header_timeout 10;
>    keepalive_timeout 2 5;
>    send_timeout 10;
>
>    server_tokens   off;
>
>    gzip on;
>    gzip_http_version 1.0;
>    gzip_vary on;
>    gzip_buffers 16 8k;
>    gzip_comp_level 6;
>    gzip_proxied any;
>    gzip_types application/octet-stream text/plain text/css
> application/x-javascript text/xml application/xml text/javascript
> application/json image/x-icon image/bmp;
>    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
>
>    index index.html;
>
>    server {
>        listen 80;
>        server_name example.com *.example.com;
>
>        error_log  /var/log/nginx/error.log;
>
>        location / {
>           uwsgi_pass unix:///tmp/example.sock;
>           uwsgi_param HTTP_X_REAL_IP $http_x_forwarded_for;
>           uwsgi_param HTTP_X_FORWARDED_FOR $proxy_add_x_forwarded_for;
>           include uwsgi_params;
>        }
>
>        location /media/ {
>           alias /opt/django/example/media/;
>        }
>
>        location /adminmedia/ {
>           alias
> /usr/local/lib/python2.6/dist-packages/django/contrib/admin/media/;
>        }
>
>        location /nginx_status {
>           stub_status on;
>           access_log on;
>           allow 127.0.0.1;
>           deny all;
>        }
>    }
> }
>
> Here's the config for apache:
>
> user  nginx nginx;
> worker_processes  1;
>
> worker_rlimit_nofile    30000;
>
> pid        /var/run/nginx.pid;
>
> events {
>    worker_connections  10240;
>    use epoll;
> }
>
> http {
>    include       mime.types;
>    default_type  application/octet-stream;
>
>    log_format  main  '$http_x_forwarded_for - $remote_user
> [$time_local] "$request" '
>                      '$status $body_bytes_sent "$http_referer" '
>                      '"$http_user_agent $request_time"';
>
>    sendfile        on;
>
>    client_body_timeout 10;
>    client_header_timeout 10;
>    keepalive_timeout 2 5;
>    send_timeout 10;
>
>    server_tokens   off;
>
>    gzip on;
>    gzip_http_version 1.0;
>    gzip_vary on;
>    gzip_buffers 16 8k;
>    gzip_comp_level 6;
>    gzip_proxied any;
>    gzip_types application/octet-stream text/plain text/css
> application/x-javascript text/xml application/xml text/javascript
> application/json image/x-icon image/bmp;
>    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
>
>    index index.html;
>
>    upstream django {
>       server 127.0.0.1:9000;
>    }
>
>    server {
>        listen 80;
>        server_name example.com;
>
>        error_log  /var/log/nginx/error.log;
>
>        location / {
>            proxy_pass          http://django;
>            proxy_redirect      off;
>
>            proxy_set_header    Host            $host;
>            proxy_set_header    X-Real-IP       $http_x_forwarded_for;
>            proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
>        }
>
>        location /media/ {
>           alias /opt/django/example/media/;
>        }
>
>        location /adminmedia/ {
>           alias
> /usr/local/lib/python2.6/dist-packages/django/contrib/admin/media/;
>        }
>
>        location /nginx_status {
>           stub_status on;
>           access_log on;
>           allow 127.0.0.1;
>           deny all;
>        }
>    }
> }
>
> Here's the Upstart init script we use to start the uWSGI server:
>
> description "uWSGI server for example"
>
> env LOGFILE=/var/log/uwsgi/uwsgi.log
> env SOCKFILE=/tmp/example.sock
> env CODEPATH=/opt/django/example
> env SETTINGS=stage
> env APPVER=00000
> env MAINT=0
>
> start on runlevel [2345]
> stop on runlevel [!2345]
>
> pre-start script
>        echo $APPVER > /tmp/example-version
>        echo $MAINT > /tmp/example-maint
> end script
>
> respawn
> exec /usr/sbin/uwsgi \
> --socket "$SOCKFILE" \
> --uid django --gid django \
> --chmod-socket \
> --threads 1 --workers 20 \
> --harakiri=60 \
> --harakiri-verbose \
> --max-requests=5000 \
> --logto "$LOGFILE" \
> --pythonpath "$CODEPATH" \
> --master \
> --env DJANGO_SETTINGS_MODULE=example.settings."$SETTINGS" \
> --env MAINTENANCE_MODE="$MAINT" \
> --env VERSION="$APPVER" \
> /opt/django/example.wsgi
>
> Thanks,
> Guy
>
> On Thu, Jan 26, 2012 at 3:00 AM,  <[email protected]> wrote:
>> Send uWSGI mailing list submissions to
>>        [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>> or, via email, send a message with subject or body 'help' to
>>        [email protected]
>>
>> You can reach the person managing the list at
>>        [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of uWSGI digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: Odd Django app 503 behaviour (Roberto De Ioris)
>>   2. Re: emperor mode - logging (Roberto De Ioris)
>>   3. Re: emperor mode - logging (Roberto De Ioris)
>>   4. static file response time vs memory usage (?ukasz Mierzwa)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 26 Jan 2012 07:23:49 +0100 (CET)
>> From: "Roberto De Ioris" <[email protected]>
>> To: "uWSGI developers and users list" <[email protected]>
>> Subject: Re: [uWSGI] Odd Django app 503 behaviour
>> Message-ID:
>>        <[email protected]>
>> Content-Type: text/plain;charset=iso-8859-1
>>
>>
>>> Since I posted the message below I've done a bit more investigation
>>> and discovered that the response returned when running under uWSGI
>>> uses chunked transfer encoding, whereas when I switch back to using
>>> apache/mod_wsgi it doesn't use chunked transfer encoding. I haven't
>>> changed the nginx configuration except to swap from an apache backend
>>> to uwsgi. The app code hasn't been changed in any way either.
>>>
>>> Anyway, here's the response header when I use Nginx/Apache/mod_wsgi:
>>>
>>> Connection    close
>>> Content-Encoding      gzip
>>> Content-Length        135
>>> Content-Type  text/html; charset=utf-8
>>> Date  Wed, 25 Jan 2012 23:15:16 GMT
>>> Server        nginx
>>> Vary  Cookie,Accept-Encoding
>>>
>>> Here's the response header when I use Nginx/uWSGI:
>>>
>>> Connection    close
>>> Content-Type  text/html; charset=utf-8
>>> Date  Wed, 25 Jan 2012 23:18:12 GMT
>>> Server        nginx
>>> Transfer-Encoding     chunked
>>> Vary  Cookie
>>>
>>>
>>>
>>
>> It looks like you have enabled gzip in apache config, that's why nginx
>> manages them differently. By the way can you post nginx config for both
>> mod_wsgi and uWSGI and uWSGI config ?
>>
>> --
>> Roberto De Ioris
>> http://unbit.it
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 26 Jan 2012 07:37:19 +0100 (CET)
>> From: "Roberto De Ioris" <[email protected]>
>> To: [email protected]
>> Subject: Re: [uWSGI] emperor mode - logging
>> Message-ID:
>>        <[email protected]>
>> Content-Type: text/plain;charset=iso-8859-1
>>
>>
>>
>>> On Jan 25, 2012 9:31 AM, "Damjan" <[email protected]> wrote:
>>
>>>
>>> I just saw/realized this while looking thru code the other day ...
>>>
>>> Does $(env_var) work?
>>
>> yes, it was added during 1.0 development to allows easy heroku deployment
>>
>>>
>>> Also looks like @(file) will do something cool, include probably.
>>
>> yes, i added it for a project of my company but i really do not know what
>> new way of config it opens :)
>>
>>>
>>> You could possibly use an env var to fill a placeholder in a common
>> config file ... not sure offhand how to include from XML though.
>>>
>>
>> check this thread, it is still a work in progress but should be enough for
>> mixing env vars abd placeholders:
>>
>> http://projects.unbit.it/uwsgi/ticket/12
>>
>> --
>> Roberto De Ioris
>> http://unbit.it
>>
>>
>>
>> --
>> Roberto De Ioris
>> http://unbit.it
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 26 Jan 2012 09:11:22 +0100 (CET)
>> From: "Roberto De Ioris" <[email protected]>
>> To: "uWSGI developers and users list" <[email protected]>
>> Subject: Re: [uWSGI] emperor mode - logging
>> Message-ID:
>>        <[email protected]>
>> Content-Type: text/plain;charset=iso-8859-1
>>
>>
>>> Now for more fun.  I tried using inherit mode to setup some defaults for
>>> my apps.
>>>
>>> So instead of starting like this:
>>>
>>>
>>> /usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals -d
>>> /var/log/uwsgi_emp.log
>>>
>>>
>>> I tried this (with my daemonize line above in the defaults.ini as
>>> daemonize = /var/log/uwsgi/%n.log) -- but it threw an error on starting.
>>>
>>>
>>> # /usr/local/bin/uwsgi --inherit /etc/uwsgi/defaults.ini
>>>
>>>
>>> So I landed here instead:
>>> /usr/local/bin/uwsgi --inherit /etc/uwsgi/defaults.ini
>>> --daemonize=/var/log/uwsgi/uwsgi.log --pidfile=/var/run/uwsgi/uwsgi.pid
>>>
>>>
>>> Sample defaults file is below.  The problem, which I verified in the log
>>> captured in the app log *above*, is none of these settings
>>>
>>> made it into the master for the app.   harakiri didnt get turned on, idle
>>> not set, etc.   Am I missing something ?
>>>
>>
>> inherit should be used in vassals config as it is meant to extend the
>> current config.
>>
>> I think you are referring to --vassals-inherit <file>
>>
>> that will automatically apply <file> to each of the vassals automatically.
>>
>> You can specify an unlimited number of vassals-inherit options. When
>> conditional options will be implmented this will allows unlimited way of
>> config.
>>
>> --
>> Roberto De Ioris
>> http://unbit.it
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 26 Jan 2012 11:00:10 +0100
>> From: ?ukasz Mierzwa <[email protected]>
>> To: [email protected]
>> Subject: [uWSGI] static file response time vs memory usage
>> Message-ID: <1381886.Qrv2aTo3pQ@kbox>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> after adding avg_rt and rss_size fields to carbon graphs I've noticed funny
>> thing: avg_rt looks is related to memory usage (or looks like it is), when
>> rss_size grows avg_rt also grows, look at the graphs below.
>>
>> average response time:
>> http://imageshack.us/photo/my-images/11/avgrt.png/
>>
>> memory usage:
>> http://imageshack.us/photo/my-images/831/rsssize.png/
>>
>> Maybe:
>> a) stats are wrong, response times are constants, only the time needed for
>> metrics gathering grows (?) or other issue related to measuring avg_rt
>> b) when memory grows uWSGI has more pages to crawl when serving request
>>
>> App used is just serving static files with --static-index, I use it to test 
>> my
>> whole setup in real life conditions. I've disabled KSM in vassal config and 
>> it
>> had no effect. The avg_rt values are small and so it is likly that this is
>> measurment error but the behaviour is very stable and happens always after
>> restarting vassal. Version used is 1.0.2.1 with carbon patch from #76.
>> I do not report this as an issue that needs resolving, it's only observation.
>>
>> ?ukasz Mierzwa
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> uWSGI mailing list
>> [email protected]
>> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>>
>>
>> End of uWSGI Digest, Vol 28, Issue 35
>> *************************************
>
>
>
> --
> Guy Knights
> Systems Administrator
> Eastside Games
> www.eastsidegamestudio.com
> [email protected]



-- 
Guy Knights
Systems Administrator
Eastside Games
www.eastsidegamestudio.com
[email protected]
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to