Gunicorn: OSError: [Errno 11] El recurso no está disponible temporalmente en la versión 19.8.1 (y 19.8.0) en Heroku

Luché con este mismo problema hoy, todo el día. Y creo que finalmente lo arreglé. Estoy usando nginx, Flask, gunicorn con eventlet y docker.

Mi salida (relevante) pip freeze :

eventlet==0.23.0
Flask==1.0.2
greenlet==0.4.14
gunicorn==19.9.0

Mi comando gunicornio:
gunicorn -b 0.0.0.0:8000 --workers 1 --worker-class eventlet --log-level=DEBUG myapp.wsgi:app

El primer síntoma fueron grandes cargas de archivos estáticos que arrojaron ERR_CONTENT_LENGTH_MISMATCH en el navegador. Obviamente, esto rompió la aplicación, ya que no se estaban cargando grandes bibliotecas JS estáticas.

El segundo síntoma fue que nginx registró lo siguiente en error.log: upstream prematurely closed connection while reading upstream

Finalmente, lo rastreé hasta un elemento de registro de gunicorn:

Socket error processing request. - [in /usr/local/lib/python2.7/dist-packages/gunicorn/glogging.py:277]
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 66, in handle
    six.reraise(*sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 56, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 129, in handle_request
    six.reraise(*sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 112, in handle_request
    resp.write_file(respiter)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 403, in write_file
    if not self.sendfile(respiter):
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 393, in sendfile
    sent += sendfile(sockno, fileno, offset + sent, count)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/_sendfile.py", line 66, in sendfile
    raise OSError(e, os.strerror(e))
OSError: [Errno 11] Resource temporarily unavailable

Mi solución final fue comenzar gunicorn con la bandera --no-sendfile , y el problema desapareció. ¿Por qué? No estoy seguro... Estoy feliz de que esté funcionando.

También vale la pena mencionar que, durante mi solución de problemas, hice todo lo posible para que mi nginx.conf se pareciera al ejemplo que se encuentra aquí: http://docs.gunicorn.org/en/stable/deploy.html

También me encuentro con este problema, 19.7.0 funciona bien

¿Esto ocurre inmediatamente o después de que se haya enviado parcialmente una respuesta larga?

Puede ser causa de archivo estático de servicio

¿Algún avance en esto? Estoy enfrentando el mismo problema en 19.9.0

Todo estaba funcionando bien y de repente comenzó a suceder.

@tilgovi , avíseme si necesita información al respecto. De repente, este problema comenzó a aparecer

Para mí, el problema se debió al trabajador eventlet. Eliminé eventlet y todo está bien ahora.

Me encuentro con el mismo problema. Y la sugerencia de @SaintSimmo me funciona bien. Este problema ocurre inmediatamente al comenzar a descargar un archivo grande. Estoy usando matraz y eventlet. Y el trabajo de descarga lo realiza send_from_directory desde Flask.
El gunicorn se inicia con el siguiente comando:
gunicorn --eventlet de clase trabajador -w 1 -b 0.0.0.0:4000 upload:app
que dará el error.
si se agrega "--no-sendfile" en el comando, no se envía ningún mensaje de error. Si el trabajo de descarga se puede realizar sin "sendfile", entonces, ¿cuándo se debe usar este "sendfile"?

gunicorn (versión 19.9.0) mismo problema con eventlet

En 19.9.0, la recomendación de @SaintSimmo de configurar --no-sendfile también funcionó para mí.

Sí, el mismo problema y después de eliminar el trabajador eventlet, funciona bien.

Cuando inicio el servidor con este comando (gunicorn -w 1 -k eventlet -b 127.0.0.1:5000 wsgi:app) recibo las siguientes excepciones y mi imagen se trunca en la respuesta del cliente.
[ERROR] Solicitud de procesamiento de error de socket.
...
BlockingIOError: [Errno 11] Recurso temporalmente no disponible

Eliminando la definición de clase trabajadora, funciona.
gunicorn -w 1 -b 127.0.0.1:5000 wsgi:aplicación

@jacebrowning y @SaintSimmo , confirmo que el parámetro adicional --no-sendfile en el comando gunicorn es efectivo.

Esto generalmente se debe a que el nproc es demasiado bajo, puede aumentar el número de nproc para el usuario que ejecuta ese programa editando el archivo ' /etc/security/limits.conf '.

¿Estás sufriendo de este problema? Si está utilizando Python 3.4 o superior, actualice su versión de Gunicorn.

Tuve el mismo problema con --worker-class. Actualicé gunicorn a 20.0.4 y se resolvió el problema.

Cambiar la clase de trabajador a gevent funcionó para mí. --worker-class gevent