Ok, one more post: I've done a bit more troubleshooting and I've found that when I put uWSGI in http mode and stop Nginx from running, I get the correct response while accessing the app through facebook. So, it looks like the problem is Nginx or uWSGI closing the connection before the response is read. However, the question that still remains is why is it doing this? Any ideas?
Thanks, Guy On Fri, Jan 27, 2012 at 5:03 PM, Guy Knights <[email protected]> wrote: > 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] -- 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
