Hi, We've got a Django application that is running with nginx and uwsgi, and we are running into an issue where the uwsgi worker will harakiri itself on POSTs. When we first started setting things up with nginx and uwsgi, we were having this problem on almost every POST that the application was handling. Adding post-buffering=1 helped, but the issue still happens on occasion, and is seemingly random. It only happens on POSTs - all GETs seem to be responded to properly. Harakiri is set to 30 seconds, but the type of POST that is being performed should never take more than 10 seconds in the worst case. Any thoughts or suggestions would be greatly appreciated.
Here is a copy of the relevant ini file uwsgi is running with: [uwsgi] socket=/tmp/uwsgi.sock chmod-socket=660 chdir=/var/www/app module=wsgi:application master=True pidfile=/tmp/app-master.pid uid=uwsgi gid=fm harakiri=30 max-requests=5000 post-buffering=1 logto=/var/log/uwsgi/app.log harakiri-verbose=false buffer-size=32768 processes=8 Sample error from nginx (with a few things somewhat redacted): 2013/04/11 21:41:31 [error] 4238#0: *24138 upstream prematurely closed connection while reading response header from upstream, client: 64.132.x.x, server: testdrive.x.com, request: "POST /input/group/58/sources/ HTTP/1.1", upstream: "uwsgi://unix:/tmp/uwsgi.sock:", host: "testdrive.x.com", referrer: "http://testdrive.x.com/input/group/58/sources/"; Sample from the uwsgi log: 2 headers in 65 bytes (1 switches on core 0) *** HARAKIRI ON WORKER 1 (pid: 15674, try: 1) *** *** backtrace of 15674 *** /usr/local/bin/uwsgi(uwsgi_backtrace+0x25) [0x446a75] /usr/local/bin/uwsgi(what_i_am_doing+0x27) [0x446ec7] /lib/libc.so.6(+0x33ba0) [0x7f49c6249ba0] /lib/libpthread.so.0(recv+0x6a) [0x7f49c7b31d3a] /usr/lib/libpython2.6.so.1.0(+0x14a601) [0x7f49c691f601] /usr/lib/libpython2.6.so.1.0(+0x14a81e) [0x7f49c691f81e] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x51a0) [0x7f49c68cb2a0] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(+0x7e08d) [0x7f49c685308d] /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f49c68254e3] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3adf) [0x7f49c68c9bdf] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x521b) [0x7f49c68cb31b] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(+0x7e08d) [0x7f49c685308d] /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f49c68254e3] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3adf) [0x7f49c68c9bdf] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x521b) [0x7f49c68cb31b] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x521b) [0x7f49c68cb31b] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x521b) [0x7f49c68cb31b] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(+0x7e08d) [0x7f49c685308d] /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f49c68254e3] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3adf) [0x7f49c68c9bdf] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(+0x7e08d) [0x7f49c685308d] /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f49c68254e3] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3adf) [0x7f49c68c9bdf] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(+0x7e08d) [0x7f49c685308d] /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f49c68254e3] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3adf) [0x7f49c68c9bdf] /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5a98) [0x7f49c68cbb98] /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f49c68ccfd0] /usr/lib/libpython2.6.so.1.0(+0x7df90) [0x7f49c6852f90] /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f49c68254e3] /usr/lib/libpython2.6.so.1.0(+0x61f1f) [0x7f49c6836f1f] /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f49c68254e3] /usr/lib/libpython2.6.so.1.0(+0xb692c) [0x7f49c688b92c] /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f49c68254e3] /usr/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43) [0x7f49c68c5403] /usr/local/bin/uwsgi(python_call+0x24) [0x454474] /usr/local/bin/uwsgi(uwsgi_request_wsgi+0x128) [0x456628] /usr/local/bin/uwsgi(wsgi_req_recv+0xbc) [0x421bac] /usr/local/bin/uwsgi(simple_loop_run+0xc3) [0x4422d3] /usr/local/bin/uwsgi(uwsgi_ignition+0x197) [0x444db7] /usr/local/bin/uwsgi(uwsgi_start+0x13dc) [0x4461bc] /usr/local/bin/uwsgi(main+0xfb8) [0x449638] /lib/libc.so.6(__libc_start_main+0xfd) [0x7f49c6234c4d] /usr/local/bin/uwsgi() [0x419fe9] *** end of backtrace *** HARAKIRI: --- uWSGI worker 1 (pid: 15674) WAS managing request /input/group/58/sources/ since Thu Apr 11 16:40:55 2013 --- *** HARAKIRI ON WORKER 1 (pid: 15674, try: 2) *** DAMN ! worker 1 (pid: 15674) died, killed by signal 9 :( trying respawn ... Respawned uWSGI worker 1 (new pid: 15790) Sample of a successful POST from the uwsgi log: [pid: 16655|app: 0|req: 11425/11421] 64.132.x.x vars in 1779 bytes} [Thu Apr 11 16:51:29 2013] POST /input/group/58/sources/ => generated 0 bytes in 1917 msecs (HTTP/1.1 302) 4 headers in 274 bytes (1 switches on core 0) Thanks! -- * Jon Chappell* [email protected]
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
