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)

Commits related to this issue

Most upvoted comments

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 disconnect event is firing properly. Would your response still be the case in this scenario?