Gunicorn: OSError: [Errno 9] Descriptor de archivo incorrecto

@ leond08 ¡ Gracias por la entrada!

Para entender cómo está sucediendo, ¿puede proporcionarnos un poco más de información?

• ¿Qué versión de Gunicorn estás probando?
• que trabajador estas usando
• cuando pasa esto?

Estoy usando la última versión de gunicorn3
Estoy usando eventlet y gevent para esto
estoy ejecutando mi aplicación de matraz - Flask-SocketIO

Comienzo mi tarea en segundo plano después de que un usuario hizo clic en el botón
Mi función de tarea en segundo plano es escuchar un evento,
después de hacer clic en el botón "HECHO", la tarea en segundo plano debe detenerse
luego envíe un mensaje de emisión a todos los usuarios

Tuve el mismo problema con aiohttp + gunicorn, observe el mismo mensaje cada vez que ctrl + c.

[INFO] Error al cerrar el socket [Errno 9] Descriptor de archivo incorrecto

No lo reproduzco. Sospecho que su aplicación está cerrando algunos fds que crean el problema anterior.

Estamos experimentando el mismo problema, lo único es que solo está sucediendo en 1 de cada 8 contenedores que se ejecutan en el enjambre de Docker.

Hemos experimentado el mismo problema con 1 de cada 9 contenedores, parece estar relacionado con Docker, Python3 y Gevent.

gunicorn 20.0.4 + aiohttp 3.6.2

Gunicorn se está ejecutando como servidor de desarrollo:

gunicorn --reload app:make_app --bind localhost:5000 --worker-class aiohttp.GunicornWebWorker --workers 2 --access-logfile -

Casi cada Ctrl + C termina con

^C[2020-05-23 21:49:50 +0200] [38524] [INFO] Handling signal: int
Exception ignored when trying to write to the signal wakeup fd:
Exception ignored when trying to write to the signal wakeup fd:
Traceback (most recent call last):
  File "/usr/lib/python3.8/asyncio/unix_events.py", line 42, in _sighandler_noop
Traceback (most recent call last):
  File "/usr/lib/python3.8/asyncio/unix_events.py", line 42, in _sighandler_noop
    def _sighandler_noop(signum, frame):
    def _sighandler_noop(signum, frame):
OSError: [Errno 9] Bad file descriptor
OSError: [Errno 9] Bad file descriptor
[2020-05-23 21:49:50 +0200] [38526] [INFO] Worker exiting (pid: 38526)
[2020-05-23 21:49:50 +0200] [38528] [INFO] Worker exiting (pid: 38528)
[2020-05-23 21:49:50 +0200] [38524] [INFO] Shutting down: Master

No importa si la aplicación manejó alguna solicitud o no.

Con Sanic 20.3.0:

^C[2020-05-26 13:24:55 +0200] [27706] [INFO] Handling signal: int
[2020-05-26 13:24:55 +0200] [27769] [INFO] Stopping server: 27769, connections: 0
[2020-05-26 13:24:55 +0200] [27769] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-05-26 13:24:55 +0200] [27769] [INFO] Worker exiting (pid: 27769)
[2020-05-26 13:24:55 +0200] [27771] [INFO] Stopping server: 27771, connections: 0
[2020-05-26 13:24:55 +0200] [27771] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-05-26 13:24:55 +0200] [27771] [INFO] Worker exiting (pid: 27771)
[2020-05-26 13:24:55 +0200] [27706] [INFO] Shutting down: Master

Lo mismo aquí con Gunicorn 20.0.4 + Uvicorn 0.11.5 clase de trabajador en cada Ctrl + C

INFO:     [12621] [gunicorn.error] Handling signal: int
INFO:     [12635] [gunicorn.error] Error while closing socket [Errno 9] Bad file descriptor
INFO:     [12634] [gunicorn.error] Error while closing socket [Errno 9] Bad file descriptor
INFO:     [12635] [gunicorn.error] Worker exiting (pid: 12635)
INFO:     [12634] [gunicorn.error] Worker exiting (pid: 12634)
INFO:     [12621] [gunicorn.error] Shutting down: Master

algún ejemplo de aplicación? Además, ¿de qué versión de Python estamos hablando?

Ubuntu 20.04, el sistema proporcionó Python 3.8.2 en virtualenv

Aplicación de ejemplo: https://github.com/zgoda/newsloop-server/tree/d603a1c10c9e8be3d998f62ccc55dd73f4677115 (con aiohttp) o https://github.com/zgoda/newsloop-server/tree/b2a8a7f09fa9848d0f384b51e . Invocación exacta de gunicorn en mi comentario anterior.

Las diferencias en la producción entre aiohttp y Sanic me hacen sospechar que hay algo mal relacionado con los trabajadores.

Mismo problema, Python 3.8.0
sanic 19.12.2
gunicorn 20.0.4

Editar: esto sucede cuando ejecuto localmente en mi Mac, pero no cuando lo ejecuto dentro de una ventana acoplable de Linux, podría ayudarlo

Hola,
Supongo que este problema https://github.com/benoitc/gunicorn/issues/2064 tiene las mismas razones.
Tenemos casi los mismos errores que en el problema, pero usamos gunicorn - 19.9.0

También estoy experimentando esto, FastAPI + los últimos trabajadores de Gunicorn y uvicorn con Python 3.8.5

Tan pronto como deje de usar uvicorn (es decir, elimine esta línea de mi configuración de gunicorn):

worker_class = "uvicorn.workers.UvicornWorker"

Los errores desaparecen.

Como se describió anteriormente, esto sucede al detener Gunicorn con Ctrl + C o al enviar una elegante señal de muerte al PID.

[2020-09-12 11:56:37 +1000] [100390] [INFO] Starting gunicorn 20.0.4
[2020-09-12 11:56:37 +1000] [100390] [INFO] Listening at: http://0.0.0.0:6000 (100390)
[2020-09-12 11:56:37 +1000] [100390] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-09-12 11:56:37 +1000] [100392] [INFO] Booting worker with pid: 100392
[2020-09-12 11:56:38 +1000] [100392] [INFO] Started server process [100392]
[2020-09-12 11:56:38 +1000] [100392] [INFO] Waiting for application startup.
[2020-09-12 11:56:38 +1000] [100392] [INFO] Application startup complete.
[2020-09-12 11:56:48 +1000] [100390] [INFO] Handling signal: term
[2020-09-12 11:56:48 +1000] [100392] [INFO] Shutting down
[2020-09-12 11:56:48 +1000] [100392] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-09-12 11:56:48 +1000] [100392] [INFO] Waiting for application shutdown.
[2020-09-12 11:56:48 +1000] [100392] [INFO] Application shutdown complete.
[2020-09-12 11:56:48 +1000] [100392] [INFO] Finished server process [100392]
[2020-09-12 11:56:48 +1000] [100392] [INFO] Worker exiting (pid: 100392)
[2020-09-12 11:56:48 +1000] [100390] [INFO] Shutting down: Master

Aquí hay una réplica exacta del problema:

[fots<strong i="6">@workstation</strong> testing]$ python3.8 -V
Python 3.8.5
[fots<strong i="7">@workstation</strong> testing]$ python3.8 -m venv ~/.virtualenv/testing
[fots<strong i="8">@workstation</strong> testing]$ source ~/.virtualenv/testing/bin/activate
(testing) [fots<strong i="9">@workstation</strong> testing]$ pip install fastapi gunicorn uvicorn
Collecting fastapi
  Using cached fastapi-0.61.1-py3-none-any.whl (48 kB)
Collecting gunicorn
  Using cached gunicorn-20.0.4-py2.py3-none-any.whl (77 kB)
Collecting uvicorn
  Using cached uvicorn-0.11.8-py3-none-any.whl (43 kB)
Collecting pydantic<2.0.0,>=1.0.0
  Using cached pydantic-1.6.1-cp38-cp38-manylinux2014_x86_64.whl (11.5 MB)
Collecting starlette==0.13.6
  Using cached starlette-0.13.6-py3-none-any.whl (59 kB)
Requirement already satisfied: setuptools>=3.0 in /home/fots/.virtualenv/testing/lib/python3.8/site-packages (from gunicorn) (47.1.0)
Collecting h11<0.10,>=0.8
  Using cached h11-0.9.0-py2.py3-none-any.whl (53 kB)
Collecting websockets==8.*
  Using cached websockets-8.1-cp38-cp38-manylinux2010_x86_64.whl (78 kB)
Collecting httptools==0.1.*; sys_platform != "win32" and sys_platform != "cygwin" and platform_python_implementation != "PyPy"
  Using cached httptools-0.1.1-cp38-cp38-manylinux1_x86_64.whl (227 kB)
Collecting uvloop>=0.14.0; sys_platform != "win32" and sys_platform != "cygwin" and platform_python_implementation != "PyPy"
  Using cached uvloop-0.14.0-cp38-cp38-manylinux2010_x86_64.whl (4.7 MB)
Collecting click==7.*
  Using cached click-7.1.2-py2.py3-none-any.whl (82 kB)
Installing collected packages: pydantic, starlette, fastapi, gunicorn, h11, websockets, httptools, uvloop, click, uvicorn
Successfully installed click-7.1.2 fastapi-0.61.1 gunicorn-20.0.4 h11-0.9.0 httptools-0.1.1 pydantic-1.6.1 starlette-0.13.6 uvicorn-0.11.8 uvloop-0.14.0 websockets-8.1
WARNING: You are using pip version 20.1.1; however, version 20.2.3 is available.
You should consider upgrading via the '/home/fots/.virtualenv/testing/bin/python3.8 -m pip install --upgrade pip' command.
(testing) [fots<strong i="10">@workstation</strong> testing]$ ls -l
total 4
-rw-rw-r-- 1 fots fots 117 Sep 12 12:13 main.py
(testing) [fots<strong i="11">@workstation</strong> testing]$ cat main.py
from fastapi import FastAPI

app = FastAPI()


@app.get("/")
async def root():
    return {"message": "Hello World"}
(testing) [fots<strong i="12">@workstation</strong> testing]$ gunicorn -k uvicorn.workers.UvicornWorker main:app
[2020-09-12 12:19:05 +1000] [105788] [INFO] Starting gunicorn 20.0.4
[2020-09-12 12:19:05 +1000] [105788] [INFO] Listening at: http://127.0.0.1:8000 (105788)
[2020-09-12 12:19:05 +1000] [105788] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-09-12 12:19:05 +1000] [105790] [INFO] Booting worker with pid: 105790
[2020-09-12 12:19:05 +1000] [105790] [INFO] Started server process [105790]
[2020-09-12 12:19:05 +1000] [105790] [INFO] Waiting for application startup.
[2020-09-12 12:19:05 +1000] [105790] [INFO] Application startup complete.
^C[2020-09-12 12:19:06 +1000] [105788] [INFO] Handling signal: int
[2020-09-12 12:19:06 +1000] [105790] [INFO] Shutting down
[2020-09-12 12:19:06 +1000] [105790] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-09-12 12:19:06 +1000] [105790] [INFO] Waiting for application shutdown.
[2020-09-12 12:19:06 +1000] [105790] [INFO] Application shutdown complete.
[2020-09-12 12:19:06 +1000] [105790] [INFO] Finished server process [105790]
[2020-09-12 12:19:06 +1000] [105790] [INFO] Worker exiting (pid: 105790)
[2020-09-12 12:19:07 +1000] [105788] [INFO] Shutting down: Master

Y aquí está la salida pip freeze :

click==7.1.2
fastapi==0.61.1
gunicorn==20.0.4
h11==0.9.0
httptools==0.1.1
pydantic==1.6.1
starlette==0.13.6
uvicorn==0.11.8
uvloop==0.14.0
websockets==8.1

Intenté instalar uvicorn y gunicorn desde GitHub (rama maestra) para asegurarme de obtener las últimas correcciones, pero el problema persistió.

Espero que esto ayude
Fotis

1. Puedo reproducir este error de registro con una configuración con solo gunicorn y uvicorn . Este mensaje de error comienza a aparecer con uvicorn==0.11.4 y no con la versión anterior 0.11.3 (tanto en OSx como en un contenedor de Linux). Esto es consistente con los informes anteriores con uvicorn, donde las versiones informadas son siempre superiores a 0.11.4 . Evidencia al final
2. El responsable de cometer este error es este uno . El problema radica en estas pocas líneas del compromiso que acabamos de mencionar. La confirmación cambia solo el orden de dos bloques de código. Si revierto ese cambio de orden, el error de registro desaparece, mientras sigo pasando el conjunto de pruebas de uvicorn
3. el mismo error de registro ocurre si uno: usa starlette y fastapi en la parte superior de la pila gunicorn+uvicorn como se informó arriba; - ejecuta la última versión de uvicorn 12.X lugar de 0.11.4 ; - ejecuta gunicorn con más de un solo uvicorn trabajador

Evidencia . En una nueva carpeta en osx, ejecute el script adjunto test.sh (probado en osx). Para realizar pruebas en el contenedor de Linux, guarde tanto el script como el Dockerfile y luego lea el encabezado del Dockerfile. También adjunto el log del script.

@benoitc , ¿qué opinas de esta confirmación en uvicorn que parece introducir el error? El problema parece estar en la interfaz entre gunicorn y uvicorn . ¿Puede comentar sobre el orden de los 2 bloques de código cambiados en la confirmación mencionada anteriormente en uvicorn ? Esto también puede ayudar a descubrir por qué sucede esto con los otros casos. Hasta ahora, esto también se ha informado con aiohttp , gevent , Flask-SocketIO sanic . Adjunto también el log del script para mayor facilidad.

log_test.log

archivo _test.sh_

#!/bin/bash
python3 -m venv venv
source venv/bin/activate
pip install gunicorn==20.0.04 uvicorn==0.11.4
# create simple uvicorn app
printf "async def app(scope, receive, send):\n    await send()\n" > example.py
# spin up gunicorn with 1 uvicorn worker, and then send TERM signal to gunicorn
gunicorn example:app -w 1 -k uvicorn.workers.UvicornWorker &
sleep 5 && pkill -f gunicorn
sleep 1
# you will see 1 log entry like this one:
# [XX] [YY] [INFO] Error while closing socket [Errno 9] Bad file descriptor

printf "\n\n[INFO] if you instead bump down uvicorn's version from 11.4 to 11.3 [Errno 9] goes away:\n\n"
pip install uvicorn==0.11.3
gunicorn example:app -w 1 -k uvicorn.workers.UvicornWorker &
sleep 5 && pkill -f gunicorn

archivo _Dockerfile_

# run with:
# docker run -it $(docker build -q .)
FROM python:3.8
COPY test.sh .
RUN chmod +x /test.sh
CMD /test.sh

Tuve exactamente el mismo problema. Este es mi caso.

Breve: Estoy intentando establecer una aplicación de prueba para Django dwebsocket con gunicorn. Cuando intento usar websocket_client para probar el resultado, después de cerrar el websocket, este error ocurre cada vez.

Ambiente :
Imagen de Docker: Python: 3.7
versión de python: python3.7.6
gunicorn: versión = 20.0.4, trabajo = gevent
Versión de Django: Django == 2.2
versión de dwebsocket: 0.5.12

Código:

view.py

from dwebsocket import accept_websocket

<strong i="16">@accept_websocket</strong>
def my_ws(request):
    if request.is_websocket():
        ws = request.websocket
        while True:
            msg = ws.wait(timeout=15)
            if msg is None:
                print('get None message')
                break
            else:
                msg = b'echo :' + msg
                ws.send(msg)
                print('send ws seccess')
        print('websocket close')

urls.py

from websocketInfo.views import  my_ws
from django.conf.urls import url

urlpatterns = [
    url(r'my_ws/$', my_ws, name='my_ws')
]

websocket_client

from websocket import create_connection
ws = create_connection("ws://127.0.0.1:8080/my_ws/")
print("Sending 'Hello, World'...")
ws.send("Hello, World")
print("Receiving...")
result = ws.recv()
print(result)
ws.close()
print('ws close')

commad para ejecutar el servidor gunicorn

gunicorn MyWebsocket.wsgi -b 0.0.0.0:8000 -w 3 -k gevent

salida de error

send ws seccess
get None message
websocket close
[2021-01-13 02:43:56 +0000] [101] [ERROR] Socket error processing request.
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 65, in handle
    util.reraise(*sys.exc_info())
  File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 625, in reraise
    raise value
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 55, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/ggevent.py", line 143, in handle_request
    super().handle_request(listener_name, req, sock, addr)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 128, in handle_request
    util.reraise(*sys.exc_info())
  File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 625, in reraise
    raise value
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 114, in handle_request
    resp.write(item)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/wsgi.py", line 326, in write
    self.send_headers()
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/wsgi.py", line 322, in send_headers
    util.write(self.sock, util.to_bytestring(header_str, "latin-1"))
  File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 286, in write
    sock.sendall(data)
  File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 523, in sendall
    return _socketcommon._sendall(self, data_memory, flags)
  File "/usr/local/lib/python3.7/site-packages/gevent/_socketcommon.py", line 367, in _sendall
    chunk_size = max(socket.getsockopt(SOL_SOCKET, SO_SNDBUF), 1024 * 1024)
  File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 156, in __getattr__
    return getattr(self._sock, name)
  File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 66, in _dummy
    raise OSError(EBADF, 'Bad file descriptor')
OSError: [Errno 9] Bad file descriptor

@ChrisXiaoShu El seguimiento de la pila que publicó nos dice que este objeto de socket específico se ha cerrado explícitamente en el nivel de Python (ahí es cuando gevent usa su _dummy para generar las mismas excepciones que el sistema operativo). Esto significa que una parte de la pila de su aplicación está cerrando el socket antes de devolver la respuesta para dejar que gunicorn lo maneje; en el momento en que ocurre el error, gunicorn ni siquiera había enviado encabezados de respuesta HTTP todavía.

Algo parecido al problema en mi caso, con la diferencia de que este error ocurre sin hacer nada. A veces después de 5 minutos, a veces después de 2 horas ...