> 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!
>
>

Unless you are using an outdated uWSGi version, you should get an error
before harakiri if the instance timeout during the wait of data.

What it looks like is that the code after the upload hang for some reason.

Add the python tracebacker, so the harakiri will return back a python
traceback:

http://uwsgi-docs.readthedocs.org/en/latest/Tracebacker.html

(and as Lukasz as already told you, do not use post-buffering with such
tiny values)


-- 
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to