502 Bad Gateway on a single django admin page

Question

I am facing a 502 Bad Gateway error on a single admin page: http://Domain.com/admin/sitecategory/add/

Although all other admin pages are working fine. I checked django logs, no errors. I ran the django test server and that specific page is working fine as well.

nginx logs:

2013/06/15 13:37:01 [error] 1906#0: *4431 upstream prematurely closed connection while reading response header from upstream, client: 46.185.176.26, server: staging.myapp.com, request: "GET /admin/sitecategory/add/ HTTP/1.1", upstream: "uwsgi://unix:///tmp/myapp-staging.socket:", host: "staging.myapp.com", referrer: "http://staging.myapp.com/admin/sitecategory/"

uwsgi logs:

*** HARAKIRI ON WORKER 1 (pid: 1942, try: 1) ***
*** backtrace of 1942 ***
uwsgi(uwsgi_backtrace+0x25) [0x43ed95]
uwsgi(what_i_am_doing+0x17) [0x43eeb7]
/lib64/libc.so.6(+0x32920) [0x7fec48662920]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x2ee6) [0x7fec48cd64a6]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50ad) [0x7fec48cd866d]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(+0x6ecbb) [0x7fec48c68cbb]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7fec48c41243]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x2a1b) [0x7fec48cd5fdb]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50ad) [0x7fec48cd866d]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x54ef) [0x7fec48cd8aaf]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50ad) [0x7fec48cd866d]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50ad) [0x7fec48cd866d]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(+0x6ecbb) [0x7fec48c68cbb]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7fec48c41243]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x2a1b) [0x7fec48cd5fdb]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50ad) [0x7fec48cd866d]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50ad) [0x7fec48cd866d]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(+0x6ebc7) [0x7fec48c68bc7]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7fec48c41243]
/usr/lib64/libpython2.6.so.1.0(PyObject_CallFunctionObjArgs+0xb0) [0x7fec48c41bb0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Unicode+0x6a) [0x7fec48c7dc6a]
/usr/lib64/libpython2.6.so.1.0(+0xb4c6a) [0x7fec48caec6a]
/usr/lib64/libpython2.6.so.1.0(+0x9e633) [0x7fec48c98633]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7fec48c41243]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x39ab) [0x7fec48cd6f6b]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x8de) [0x7fec48cd9c7e]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50ad) [0x7fec48cd866d]
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x54ef) [0x7fec48cd8aaf]
*** end of backtrace ***
HARAKIRI: --- uWSGI worker 1 (pid: 1942) WAS managing request /admin/sitecategory/add/ since Sat Jun 15 16:36:49 2013 ---
[pid: 1818|app: 0|req: 5/5] 46.185.176.26 () {38 vars in 694 bytes} [Sat Jun 15 16:37:01 2013] GET /favicon.ico => generated 5939 bytes in 113 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
*** HARAKIRI ON WORKER 1 (pid: 1942, try: 2) ***
DAMN ! worker 1 (pid: 1942) died, killed by signal 9 :( trying respawn ...

I run uwsgi using upstart:

exec uwsgi -b 25000 --chdir=/www/python/apps/myapp-staging/ --module=wsgi:application --env DJANGO_SETTINGS_MODULE=settings --socket=/tmp/myapp-staging.socket --processes=3  --harakiri=10  --max-requests=5000  --vacuum --master --pidfile=/tmp/myapp-staging-master.pid --uid=220 --gid=499 --daemonize=/www/uwsgi/myapp-staging.log

and my nginx configs are as follows:

server {
    server_name staging.myapp.com;

    root /www/python/apps/myapp-staging/;



    access_log /www/nginx/staging.myapp.com.access.log;
    error_log /www/nginx/staging.myapp.com.error.log;

    location /static/ {
        alias /www/python/apps/myapp-staging/static/;
        expires 30d;
    }

    location /media/ {
        alias /www/python/apps/myapp-staging/media/;
        expires 30d;
    }

    location / {
        uwsgi_pass unix:///tmp/myapp-staging.socket;
        include uwsgi_params;
        proxy_read_timeout 360;
    }
}

Anything wrong am doing here?

Thanks

Do http://stackoverflow.com/questions/7273725/django-error-when-send-emails-thrue-google-apps/7279065 and http://stackoverflow.com/questions/3970495/nginx-connection-reset-response-from-uwsgi-lost help? — okm, Jun 15 '13 at 13:46
This seems to be the case when doing POST request but in my case, even GET requests fail — Maverick, Jun 15 '13 at 13:52
Does the page contain any heavy calculation, for example a foreign key form field w/ tons of items? — okm, Jun 15 '13 at 14:09
Yes it does... however, in the ModelAdmin i used raw_id_fields to prevent fetching related data but the problem still persists — Maverick, Jun 15 '13 at 14:20

score 1 · Answer 1 · answered Jun 15 '13 at 16:46

1

Find one error in your nginx config file

        proxy_read_timeout 360;

should read

        uwsgi_read_timeout 360;

HttpUwsgiModule module has its own timeout directives.

http://wiki.nginx.org/HttpUwsgiModule#uwsgi_read_timeout

answered Jun 15 '13 at 16:46

Chuan Ma

9,754
2
45
37

score 1 · Accepted Answer · answered Jun 16 '13 at 05:36

1

You set 10 seconds harakiri for a heavy view that very probably will require more time.

Just remove it, measure how much time that view needs and reset it accordingly

answered Jun 16 '13 at 05:36

roberto

12,723
44
30

502 Bad Gateway on a single django admin page

2 Answers2