> 2014-05-16 19:37 GMT+02:00 Roberto De Ioris <[email protected]>: > >> >> > Hi, >> > >> > I'm using Django + uwsgi + nginx, recently I've observed the a.m. >> IOError >> > in the logs: >> > >> > See: https://dpaste.de/HRDQ >> > >> > Any idea? >> > >> > It seems like it started after a recent upgrade of uwsgi to >> > 2.0.3-1chl1~precise1 but I'm not sure about that. >> > >> > >> >> you should get at least another log line which reports why the error was >> generated (before the python traceback, unless you are reporting the >> traceback sent by email, in such a case you should check your logs >> 'manually'). >> >> If you were using a uWSGI version < 1.4 such errors were reported only >> in >> logs without python traceback so it is pretty normal you never noted >> them >> > > > Hi Roberto, > > you're absolutely right, this is the error in the log: > > [pid: 3306|app: 0|req: 5748/49068] 85.50.14.244 () {116 vars in 2228 > bytes} > [Fri May 16 18:27:07 2014] GET /it/admin/resources/accomodation/ => > generated 7872 bytes in 927 msecs (HTTP/1.1 200) 11 headers in 488 bytes > (1 > switches on core 0) > Fri May 16 18:27:09 2014 - [uwsgi-body-read] Error reading 16384 bytes. > Content-Length: 488288 consumed: 114688 left: 373600 message: Client > closed > connection > Fri May 16 18:27:09 2014 - SIGPIPE: writing to a closed pipe/socket/fd > (probably the client disconnected) on request > /it/admin/filebrowser/upload_file/ (ip 151.27.85.18) !!! > Fri May 16 18:27:09 2014 - uwsgi_response_writev_headers_and_body_do(): > Broken pipe [core/writer.c line 287] during POST > /it/admin/filebrowser/upload_file/ (151.27.85.18) > IOError: write error > [pid: 3306|app: 0|req: 5749/49069] 151.27.85.18 () {120 vars in 2487 > bytes} > [Fri May 16 18:27:09 2014] POST /it/admin/filebrowser/upload_file/ => > generated 0 bytes in 279 msecs (HTTP/1.1 500) 6 headers in 0 bytes (0 > switches on core 0) > > > It seems like the client closed the connection during the upload, correct? > > Is this a client problem then? If yes, I believe that this error should > not > be reported by Django but silently fail... > >
It is all about statistics, when we introduce a behaviour we ask our customer what the default should be. Basically always, there is no consensus, so we go for the majority. In this case raising an exception was the choice (the fact that Django send an email for it is something not heavily related, but you can turn it off selectively using a middleware). side note: take in account that common attacks like slowloris will trigger this thing, so disabling it could not be a really good idea :) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
