Gunicorn: OSError : [Errno 11] Ressource temporairement indisponible sur la version 19.8.1 (et 19.8.0) sur Heroku

Je me suis battu avec ce même problème aujourd'hui, toute la journée. Et je _pense_ que j'ai finalement corrigé le problème. J'utilise nginx, Flask, gunicorn avec eventlet et docker.

Ma sortie (pertinente) pip freeze :

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

Ma commande gunicorn:
gunicorn -b 0.0.0.0:8000 --workers 1 --worker-class eventlet --log-level=DEBUG myapp.wsgi:app

Le premier symptôme était de gros chargements de fichiers statiques lançant ERR_CONTENT_LENGTH_MISMATCH dans le navigateur. De toute évidence, cela a cassé l'application, car les grandes bibliothèques JS statiques n'étaient pas chargées.

Le deuxième symptôme était que nginx enregistrait ce qui suit dans error.log : upstream prematurely closed connection while reading upstream

Enfin, je l'ai retracé jusqu'à un élément de journal 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

Ma solution finale était de démarrer gunicorn avec le drapeau --no-sendfile , et le problème a disparu. Pourquoi? Pas sûr... Je suis juste content que ça marche.

Il convient également de mentionner que lors de mon dépannage, j'ai fait de mon mieux pour que mon nginx.conf ressemble à l'exemple trouvé ici : http://docs.gunicorn.org/en/stable/deploy.html

Je rencontre aussi ce problème, 19.7.0 fonctionne bien

Cela se produit-il immédiatement ou après l'envoi partiel d'une longue réponse ?

Peut être la cause d'un fichier statique

Une mise à jour pour ceci? Je suis confronté au même problème dans 19.9.0

Tout fonctionnait bien et tout d'un coup ça a commencé à arriver.

@tilgovi faites-moi savoir si vous avez besoin d'informations à ce sujet. Tout d'un coup, ce problème a commencé à apparaître

Pour moi, le problème était dû au travailleur eventlet. J'ai supprimé eventlet et tout va bien maintenant.

Je rencontre le même problème. Et la suggestion de @SaintSimmo fonctionne bien pour moi. Ce problème se produit immédiatement lors du démarrage du téléchargement d'un fichier volumineux. J'utilise flask et eventlet. Et le travail de téléchargement est effectué par send_from_directory de Flask.
Le gunicorn est démarré dans la commande suivante :
gunicorn --worker-class eventlet -w 1 -b 0.0.0.0:4000 upload:app
qui donnera l'erreur.
si "--no-sendfile" est ajouté dans la commande, aucun message d'erreur n'est envoyé. Si le travail de téléchargement peut être effectué sans "sendfile", alors quand ce "sendfile" doit-il être utilisé ?

gunicorn (version 19.9.0) même problème avec eventlet

Le 19.9.0, la recommandation de @SaintSimmo de définir --no-sendfile a également fonctionné pour moi.

Oui, le même problème et après avoir supprimé le travailleur eventlet, cela fonctionne bien.

Lorsque je démarre le serveur avec cette commande (gunicorn -w 1 -k eventlet -b 127.0.0.1:5000 wsgi:app), je reçois les exceptions ci-dessous et mon image est tronquée sur la réponse du client.
[ERROR] Erreur de socket lors du traitement de la demande.
...
BlockingIOError : [Errno 11] Ressource temporairement indisponible

En supprimant la définition de la classe de travail, cela fonctionne.
gunicorn -w 1 -b 127.0.0.1:5000 wsgi:app

@jacebrowning et @SaintSimmo , je confirme que le paramètre supplémentaire --no-sendfile dans la commande gunicorn est efficace.

Cela est généralement dû au fait que le nproc est trop peu nombreux, vous pouvez augmenter le nombre de nproc pour l'utilisateur qui exécute ce programme en éditant le fichier ' /etc/security/limits.conf '.

Souffrez-vous de ce problème ? Si vous utilisez Python 3.4 ou supérieur, mettez à jour votre version de Gunicorn.

J'ai eu le même problème avec --worker-class. J'ai mis à jour gunicorn vers 20.0.4 et le problème a été résolu.

Changer la classe ouvrière en gevent a fonctionné pour moi. --worker-class gevent