Flask-SocketIO: [ERROR] Socket error processing request.
I get the following error every now and then when running with gunicorn. I am not sure why or when this happens.
[2015-10-18 19:56:52 -0500] [17657] [ERROR] Socket error processing request.
Traceback (most recent call last):
File ".../venv/lib/python2.7/site-packages/gunicorn/workers/async.py", line 64, in handle
six.reraise(exc_info[0], exc_info[1], exc_info[2])
File ".../venv/lib/python2.7/site-packages/gunicorn/workers/async.py", line 52, in handle
self.handle_request(listener_name, req, client, addr)
File ".../venv/lib/python2.7/site-packages/gunicorn/workers/async.py", line 127, in handle_request
six.reraise(*sys.exc_info())
File ".../venv/lib/python2.7/site-packages/gunicorn/workers/async.py", line 113, in handle_request
resp.write(item)
File ".../venv/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 324, in write
self.send_headers()
File ".../venv/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 320, in send_headers
util.write(self.sock, util.to_bytestring(header_str))
File "...venv/lib/python2.7/site-packages/gunicorn/util.py", line 300, in write
sock.sendall(data)
File ".../venv/lib/python2.7/site-packages/eventlet/greenio/base.py", line 376, in sendall
tail = self.send(data, flags)
File ".../venv/lib/python2.7/site-packages/eventlet/greenio/base.py", line 359, in send
total_sent += fd.send(data[total_sent:], flags)
File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 174, in _dummy
raise error(EBADF, 'Bad file descriptor')
error: [Errno 9] Bad file descriptor
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Comments: 15 (10 by maintainers)
These are benign errors that I believe to be caused by gunicorn, eventlet and gevent. The error means that the server tried to write or read from a socket that out of nowhere got closed. The issue occurs when the client abruptly leaves a HTTP or WebSocket connection, without properly closing it. The typical case is when you close the browser window. In many cases the web server detects this condition and suppresses the “broken pipe”, “bad file descriptor” or similar error that results from it, but there are several situations where this error is not capture, so you see it in your log.
I see that’s the long-polling request is finished and the connection is upgraded to websocket. And whenever a client leaves, I see that
disconnectevent is firing properly. Would your response still be the case in this scenario?