Gunicorn: Prises

Y a-t-il quelque chose d'intéressant en amont de gunicorn dans votre pod, comme un proxy inverse, nginx ?

Non, pas de proxy, pas de nginx

J'ai exactement le même problème :confused:

En amont, nous avons HAProxy et sur son format de journal HTTP, l'état de la session à la déconnexion (voir http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#8.5) il enregistre ces erreurs comme CH-- signifiant :

• C : la session TCP a été interrompue de manière inattendue par le client.
• H : le proxy attendait une réponse complète et valide HEADERS du serveur (HTTP uniquement).

Donc, si je comprends bien, le client a fermé la connexion alors que gunicorn envoyait toujours la réponse.

Des indices sur ce qui fait avorter le client ? Attendait-il longtemps que gunicorn envoie des en-têtes de réponse complets ?

@javabrett, cela ne semble pas être le cas, du moins sur les quelques messages de journal que j'ai consultés, il s'agit principalement d'images ou d'autres actifs, cela ne devrait donc pas prendre beaucoup de temps.

Le client a peut-être fermé le navigateur ou toute autre action qui fermerait brusquement la connexion ? :pensée:

@gforcada utilisez-vous le protocole proxy avec haproxy ?

@benoitc pas à ma connaissance

quelqu'un va quelque part avec ça? Je n'ai pas grand-chose à contribuer, sauf exactement la même erreur.

Ma configuration se compose d'un équilibreur de charge qui est utilisé pour mettre fin à SSL et transmettre les demandes à une application Django s'exécutant dans un conteneur Docker. Je ne sais pas avec quoi le LB est implémenté - c'est un produit Digital Ocean.

Je suis à peu près certain que cela est lié à l'équilibreur de charge car j'ai la même application en cours d'exécution dans un autre conteneur qui n'est pas derrière un LB et qui n'a jamais eu ce problème.

Des idées sur la cause profonde et comment prévenir?

Je me demande s'il y a une action ici. S'il s'agit d'une déconnexion client normale, nous pourrions peut-être faire taire l'erreur et peut-être enregistrer une déconnexion dans le journal d'accès, mais sinon, je ne sais pas quoi faire.

Je viens d'avoir la même erreur qui a fait planter notre serveur Web de surveillance :

[2019-06-10 11:38:25 +0200] [27989] [CRITICAL] WORKER TIMEOUT (pid:17906)
[2019-06-10 11:38:25 +0200] [17906] [INFO] Worker exiting (pid: 17906)
[2019-06-10 11:38:25 +0200] [17924] [INFO] Booting worker with pid: 17924
[2019-06-10 11:38:37 +0200] [17922] [ERROR] Socket error processing request.
Traceback (most recent call last):
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected
[2019-06-10 11:38:47 +0200] [27989] [CRITICAL] WORKER TIMEOUT (pid:17920)
[2019-06-10 11:38:47 +0200] [17920] [INFO] Worker exiting (pid: 17920)

J'ai eu la même chose avec le pod exécutant l'image docker dpage/pgadmin4:4.2

OSError : [Errno 107] Socket non connecté
[2019-06-14 12:20:32 +0000] [77] [ERREUR] Demande de traitement d'erreur de socket.
Traceback (appel le plus récent en dernier) :
Fichier "/usr/local/lib/python3.6/site-packages/gunicorn/workers/gthread.py", ligne 274, dans le handle
req = six.next(conn.parser)
Fichier "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", ligne 41, dans __next__
self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
Fichier "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 181, dans __init__
super(Request, self).__init__(cfg, unreader)
Fichier "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 54, dans __init__
inutilisé = self.parse(self.unreader)
Fichier "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 230, en parse
self.headers = self.parse_headers(data[:idx])
Fichier "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 74, dans parse_headers
remote_addr = self.unreader.sock.getpeername()

Cela ressemble beaucoup à : https://github.com/benoitc/gunicorn/issues/2070

Je reçois occasionnellement cette erreur sur Google Cloud Run hébergé. Vous trouverez ci-dessous une version simplifiée de notre définition de conteneur :

FROM ubuntu:18.04

ENV APP_HOME /app
WORKDIR $APP_HOME

RUN apt-get update \
  && apt-get install --no-install-recommends -y python3 python3-pip \
  && rm -rf /var/lib/apt/lists/*

RUN pip3 install --compile --no-cache-dir --upgrade pip setuptools

RUN mkdir invoice_processing && \
    pip install --compile --disable-pip-version-check --no-cache-dir flask gunicorn

COPY app.py ./
CMD exec gunicorn --bind :$PORT --workers 1 --threads 1 app:app

Stackdriver affiche la trace de pile suivante :

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/arbiter.py", line 583, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/base.py", line 134, in init_process
    self.run()
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/sync.py", line 124, in run
    self.run_for_one(timeout)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/sync.py", line 68, in run_for_one
    self.accept(listener)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/sync.py", line 27, in accept
    client, addr = listener.accept()
  File "/usr/lib/python3.6/socket.py", line 205, in accept
    fd, addr = self._accept()
OSError: [Errno 107] Transport endpoint is not connected

Même problème que OP ici. Utilisation de Google Cloud Platform, Python 3.7, gunicorn 19.9.0

Traceback (most recent call last):
  File "/env/lib/python3.7/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/env/lib/python3.7/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected
 timestamp:  "2019-07-30T15:23:55.435130Z"

J'ai exactement le même problème 😕

Exactement le même problème que GAEfan. Exécuter une application Flask avec Python 3.7 dans App Engine Standard Env.

Même problème ici

J'ai le même problème lors de l'exécution de l'application Django avec Python 3.7 dans Google App Engine.

Traceback (appel le plus récent en dernier) : fichier "/env/lib/python3.7/site-packages/gunicorn/workers/sync.py", ligne 134, dans handle req = six.next(parser) File "/env/ lib/python3.7/site-packages/gunicorn/http/parser.py", ligne 41, dans __next__ self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count) Fichier "/env/lib /python3.7/site-packages/gunicorn/http/message.py", ligne 181, dans __init__ super(Request, self).__init__(cfg, unreader) Fichier "/env/lib/python3.7/site-packages /gunicorn/http/message.py", ligne 54, dans __init__ unused = self.parse(self.unreader) Fichier "/env/lib/python3.7/site-packages/gunicorn/http/message.py", ligne 230, dans l'analyse self.headers = self.parse_headers(data[:idx]) Fichier "/env/lib/python3.7/site-packages/gunicorn/http/message.py", ligne 74, dans parse_headers remote_addr = self .unreader.sock.getpeername() OSError : [Errno 107] Le point de terminaison de transport n'est pas connecté

Même problème avec GAE python 3.7 gunicorn et fastapi/uvicorn.

Même problème Google Cloud Run

de quel type de demande parle-t-on ?

même problème dans le moteur d'application google. demande POST. arrive de manière incohérente. Application de flacon. @benoitc s'il vous plaît laissez-moi savoir quelles informations seraient utiles et je peux poster.

Même problème également, Google App Engine, demande POST également, application Flask. Cela semblait avoir commencé lorsque je suis passé à un code de point d'entrée personnalisé au lieu de laisser celui par défaut. Le point d'entrée personnalisé est le suivant (dans Google App Engine, vous le définissez dans un fichier app.yaml) :

gunicorn -b :$PORT --timeout 1200 server.main:app

Le point d'entrée par défaut ne définit rien (je ne sais pas ce qui est utilisé comme point d'entrée par défaut).

Je ne sais pas si cela a commencé à cause de cela, mais je l'ai remarqué lorsque j'ai apporté ce changement (entre autres changements).

Non, pas de proxy, pas de nginx

J'utilisais gunicorn sans nginx . J'avais le même problème. Ma configuration fonctionne sur Openshift .
gunicorn --chdir /src/app wsgi:application --bind 0.0.0.0:8000 --workers 4 --timeout 180 -k gevent

https://stackoverflow.com/questions/58389201/gunicorn-is-failing-with-oserror-errno-107-transport-endpoint-is-not-connecte

le stand de la question

Même problème également, Google App Engine, demande POST également, application Flask. Cela semblait avoir commencé lorsque je suis passé à un code de point d'entrée personnalisé au lieu de laisser celui par défaut. Le point d'entrée personnalisé est le suivant (dans Google App Engine, vous le définissez dans un fichier app.yaml) :

gunicorn -b :$PORT --timeout 1200 server.main:app

Le point d'entrée par défaut ne définit rien (je ne sais pas ce qui est utilisé comme point d'entrée par défaut).

Je ne sais pas si cela a commencé à cause de cela, mais je l'ai remarqué lorsque j'ai apporté ce changement (entre autres changements).

qu'entends-tu par point d'entrée ? pouvez-vous publier un journal de débogage et la manière dont la demande est effectuée ? (http brut aiderait)

le stand de la question

Même problème également, Google App Engine, demande POST également, application Flask. Cela semblait avoir commencé lorsque je suis passé à un code de point d'entrée personnalisé au lieu de laisser celui par défaut. Le point d'entrée personnalisé est le suivant (dans Google App Engine, vous le définissez dans un fichier app.yaml) :
gunicorn -b :$PORT --timeout 1200 server.main:app
Le point d'entrée par défaut ne définit rien (je ne sais pas ce qui est utilisé comme point d'entrée par défaut).
Je ne sais pas si cela a commencé à cause de cela, mais je l'ai remarqué lorsque j'ai apporté ce changement (entre autres changements).

qu'entends-tu par point d'entrée ? pouvez-vous publier un journal de débogage et la manière dont la demande est effectuée ? (http brut aiderait)

Je pense qu'il fait référence au fait que vous spécifiez explicitement le chemin app que _gunicorn_ doit importer, rechercher et exécuter, comme le server.main:app dans son exemple.

LE : Peut-être que l'exemple mis à jour ici aide : https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/standard_python37/hello_world (donc, en gros, vous devez laisser le service gérer comment le serveur devrait être commencé)

Tout d'abord, @benoitc MERCI. Votre travail est génial.

Je rencontre également le même problème sur Google Cloud Run w/gunicorn. Je poste ce que j'ai, bien que ce ne soit probablement pas unique, en lisant ce qui précède. J'exécute une application Flask avec Gunicorn comme serveur (et sans proxy) dans un conteneur Docker.

Le retraçage (depuis la console GC) :

  File "/usr/local/lib/python3.7/site-packages/gunicorn/arbiter.py", line 583, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 104, in init_process
    super(ThreadWorker, self).init_process()
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base.py", line 134, in init_process
    self.run()
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 211, in run
    callback(key.fileobj)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 127, in accept
    sock, client = listener.accept()
  File "/usr/local/lib/python3.7/socket.py", line 212, in accept
    fd, addr = self._accept()
OSError: [Errno 107] Transport endpoint is not connected

Et la sortie analysée de Google de ce qui précède :

OSError: [Errno 107] Transport endpoint is not connected
at accept (/usr/local/lib/python3.7/socket.py:212)
at accept (/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py:127)
at run (/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py:211)
at init_process (/usr/local/lib/python3.7/site-packages/gunicorn/workers/base.py:134)
at init_process (/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py:104)
at spawn_worker (/usr/local/lib/python3.7/site-packages/gunicorn/arbiter.py:583)

S'il y a autre chose que je peux fournir ou faire pour aider ici, faites-le moi savoir.

Un PR serait le bienvenu pour gérer ENOTCONN gracieusement pour tous les travailleurs. Veuillez poster ici si vous commencez à travailler sur cela et je serais heureux d'examiner un PR. Je suis sûr que certains sur ce fil seraient heureux d'aider à tester une branche.

Même problème, Google App Engine, gunicorn servant une application Django, un petit pourcentage de requêtes meurt comme ceci :

entrypoint: gunicorn -b :$PORT wsgi_api:application

Un PR serait le bienvenu pour gérer ENOTCONN gracieusement pour tous les travailleurs. Veuillez poster ici si vous commencez à travailler sur cela et je serais heureux d'examiner un PR. Je suis sûr que certains sur ce fil seraient heureux d'aider à tester une branche.

Je suis l'un de ceux sur ce fil heureux d'aider à tester, alors s'il vous plaît ping moi si je peux aider.

Un PR serait le bienvenu pour gérer ENOTCONN gracieusement pour tous les travailleurs. Veuillez poster ici si vous commencez à travailler sur cela et je serais heureux d'examiner un PR. Je suis sûr que certains sur ce fil seraient heureux d'aider à tester une branche.

Je suis l'un de ceux sur ce fil heureux d'aider à tester, alors s'il vous plaît ping moi si je peux aider.

Je suis heureux d'aider à tester le PR. Si besoin d'aide s'il vous plaît ping moi.

Je suis heureux d'aider à tester le PR. Si besoin d'aide s'il vous plaît ping moi.

Un PR serait le bienvenu pour gérer ENOTCONN gracieusement pour tous les travailleurs. Veuillez poster ici si vous commencez à travailler sur cela et je serais heureux d'examiner un PR. Je suis sûr que certains sur ce fil seraient heureux d'aider à tester une branche.

La cause première de ce problème avec la dernière version de gunicorn==19.9.0 . J'ai été déplacé pour utiliser l'ancienne version de gunicorn==19.7.1 . J'ai pu courir sans problème. Veuillez essayer avec l'ancienne version.

essayez plutôt le dernier maître. 20.0 viendra enfin aujourd'hui, j'ai été détourné.

À quoi ressemble votre point de terminaison de vérification de l'état ? Comment y répondez-vous, fermez-vous la connexion ? définissez-vous l'en-tête de longueur et co? Je ne sais pas pourquoi un bilan de santé est effectué par la poste. ça a l'air bizarre...

@cmin764 est-ce que fflask définit un en-tête par défaut ? je vais essayer mais ce serait interressant de ser ho la réponse a l'air

@benoitc Lorsque j'utilisais le contrôle de santé du point gunicorn==19.9.0 terminaison

plus ancien gunicorn==19.7.1 point

Je testerai également la dernière version 20.0.

Non, pas de proxy, pas de nginx

J'utilisais gunicorn sans nginx . J'avais le même problème. Ma configuration fonctionne sur Openshift .
gunicorn --chdir /src/app wsgi:application --bind 0.0.0.0:8000 --workers 4 --timeout 180 -k gevent

https://stackoverflow.com/questions/58389201/gunicorn-is-failing-with-oserror-errno-107-transport-endpoint-is-not-connecte

avec l'ancienne version gunicorn=19.7.1 I was not able to run with the gevent`. J'ai changé ma commande gunicorn

gunicorn apps.wsgi:application --bind 0.0.0.0:8000 --workers 4 --timeout 180

Je regarde les changements depuis cette version pour voir s'il y a une raison à cela. Merci pour les commentaires!

L'utilisation de la version 19.7.1 (rétrogradation par rapport à la plus récente) fonctionnait dans l'environnement du moteur d'application Google avec des files d'attente de transmission alimentant les travailleurs et les travailleurs se parlant via http.

L'utilisation de la version 19.7.1 (rétrogradation par rapport à la plus récente) fonctionnait dans l'environnement du moteur d'application Google avec des files d'attente de transmission alimentant les travailleurs et les travailleurs se parlant via http.

C'est mon cas d'utilisation. Je vais tenter le coup.

as-tu essayé la dernière version ?

J'ai essayé la dernière version 20.0.0 sur Openshift (openshift v3.11.135, kubernetes v1.11.0) - la même erreur se produit. L'erreur que j'ai observée est déclenchée sur une charge plus élevée (tests d'intégration exécutant 20 travailleurs parallèles). L'augmentation du nombre de pods réduit l'occurrence d'erreurs, laissant un seul pod entraîne une erreur garantie. C'est une configuration de 3 travailleurs de synchronisation. 19.7.1 ne montre aucune erreur sur les journaux de pod , mais le consommateur externe rencontre le même EOF inattendu lors de la connexion, comme avec la dernière version. Donc, la version dégradante n'aide pas.

2019-11-12 16:08:56,982 ERREUR gunicorn.error glogging 277 glogging.py Demande de traitement d'erreur de socket.
Traceback (appel le plus récent en dernier) :
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", ligne
134, dans la poignée
req = six.next (analyseur)
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", ligne 41, dans __next__
self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 181, dans __init__
super(Request, self).__init__(cfg, unreader)
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 54, dans __init__
inutilisé = self.parse(self.unreader)
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 230, en parse
self.headers = self.parse_headers(data[:idx])
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 74, dans parse_headers
remote_addr = self.unreader.sock.getpeername()
OSError : [Errno 107] Le point de terminaison de transport n'est pas connecté

J'ai essayé la dernière version 20.0.0 sur Openshift (openshift v3.11.135, kubernetes v1.11.0) - la même erreur se produit. L'erreur que j'ai observée est déclenchée sur une charge plus élevée (tests d'intégration exécutant 20 travailleurs parallèles). L'augmentation du nombre de pods réduit l'occurrence d'erreurs, laissant un seul pod entraîne une erreur garantie. C'est une configuration de 3 travailleurs de synchronisation. 19.7.1 ne montre aucune erreur sur les journaux de pod , mais le consommateur externe rencontre le même EOF inattendu lors de la connexion, comme avec la dernière version. Donc, la version dégradante n'aide pas.

2019-11-12 16:08:56,982 ERREUR gunicorn.error glogging 277 glogging.py Demande de traitement d'erreur de socket.
Traceback (appel le plus récent en dernier) :
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", ligne
134, dans la poignée
req = six.next (analyseur)
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", ligne 41, dans la suite
self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 181, dans init
super(Demande, soi). init (cfg, unreader)
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 54, dans init
inutilisé = self.parse(self.unreader)
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 230, en parse
self.headers = self.parse_headers(data[:idx])
Fichier "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", ligne 74, dans parse_headers
remote_addr = self.unreader.sock.getpeername()
OSError : [Errno 107] Le point de terminaison de transport n'est pas connecté

Pouvez-vous essayer d'augmenter le délai d'attente du

Pouvez-vous essayer d'augmenter le délai d'attente du

Suite à cette piste, nous avons trouvé un problème : la configuration de la sonde de préparation Openshift était trop optimiste (l'application a pris trop de temps pour certaines demandes), et en cas d'échec, l'équilibreur de charge externe (AVI) a récupéré cet événement et a expulsé le pod du pool d'équilibrage de charge.

J'ai récemment rencontré ce problème avec gunicorn=19.9.0. Un redémarrage a résolu le problème. Je suis déployé sur Google Kubernetes Engine. L'application est une application de flacon -
entrée:
command: ["sh", "-c", "gunicorn -b 0.0.0.0:$${PORT} -c gunicorn_config.py run:app"]
configuration :

worker_temp_dir = '/dev/shm'
worker_class = 'gthread'
worker = 2
threads = 2
worker_connections = 1000
timeout = 180
keepalive = 2
backlog = 2048
accesslog = '-'
errorlog = '-'

Erreur:
Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/gunicorn/workers/gthread.py", line 274, in handle req = six.next(conn.parser) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/parser.py", line 41, in __next__ self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/message.py", line 181, in __init__ super(Request, self).__init__(cfg, unreader) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/message.py", line 54, in __init__ unused = self.parse(self.unreader) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/message.py", line 230, in parse self.headers = self.parse_headers(data[:idx]) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/message.py", line 74, in parse_headers remote_addr = self.unreader.sock.getpeername() File "/usr/local/lib/python2.7/socket.py", line 228, in meth return getattr(self._sock,name)(*args) error: [Errno 107] Transport endpoint is not connected

La solution actuelle est-elle de rétrograder à 19.7.1 ?

Quelqu'un peut-il partager un référentiel avec des instructions de déploiement que je peux utiliser pour reproduire le problème ? Je suis heureux de l'examiner, mais je veux m'assurer que je sais exactement comment le configurer.

Salut @tilgovi Fastapi utilise gunicorn en production.
Ce référentiel a une version minimale et a montré la même erreur. Vous pouvez essayer, j'ai eu cette erreur chez App Engine, je ne sais pas si elle se réplique avec d'autres environnements. Ce référentiel, pourrait-il aider à reproduire le problème ?

Même problème ici :
gunicorn 19.9.0 + GKE s'est également produit lorsque nous avions affaire à une charge élevée.

cmin

Pas sûr, mais tout semble redevenu normal maintenant.

Ceci est mon app.yaml

runtime: python37
entrypoint: gunicorn -b :$PORT truestory:app


handlers:
- url: /static
  static_dir: truestory/static

- url: /favicon\.ico
  static_files: truestory/static/img/favicon.ico
  upload: truestory/static/img/favicon\.ico

- url: /.*
  secure: always
  redirect_http_response_code: 301
  script: auto

Et la production de Makefile :

run: export FLASK_CONFIG = production
run:
    # Run main server in production mode with Gunicorn (remote database).
    <strong i="12">@echo</strong> "[i] Starting server with Gunicorn."
    gunicorn -b :$(PORT) truestory:app

Alors peut-être que c'était quelque chose de temporaire sur GAE.

J'ai le même problème. Gunicorn avec gevent, juste un Google HTTP LB devant. (pas de Nginx, ou autre proxy inverse). Les choses fonctionnent bien pendant des semaines, mais de temps en temps, j'obtiens :

Traceback (most recent call last):
  File "XXX/gunicorn/workers/base_async.py", line 65, in handle
    util.reraise(*sys.exc_info())
  File "XXX/gunicorn/util.py", line 625, in reraise
    raise value
  File "XXX/gunicorn/workers/base_async.py", line 48, in handle
    req = next(parser)
  File "XXX/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "XXX/gunicorn/http/message.py", line 186, in __init__
    super().__init__(cfg, unreader)
  File "XXX/gunicorn/http/message.py", line 53, in __init__
    unused = self.parse(self.unreader)
  File "XXX/gunicorn/http/message.py", line 235, in parse
    self.headers = self.parse_headers(data[:idx])
  File "XXX/gunicorn/http/message.py", line 73, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected

Gunicorne 20.0.4.

Le fait que plusieurs personnes ont signalé que son "se produit sous une charge élevée" ou que, dans mon cas, cette chose se produit "quelques fois par mois" ressemble à une sorte de condition de course.

@JordanP fo vous avez une erreur du côté de google ? Comment envoyer le ping depuis Google LB ? Est-ce qu'il expire du côté de google LB ?

Il s'exécute dans Kubernetes, le bilan de santé est un HTTP, très conservateur (timeout 5 sec, 10 échecs consécutifs avant de marquer les conteneurs comme morts).

Du côté de Google, le HTTP LB devant Gunicorn a renvoyé plus de 40k 502 erreurs (en quelques minutes) avec la raison suivante : "backend_timeout" :

J'ai eu 4 répliques (4 conteneurs), ils se sont tous écrasés ~ en même temps cette nuit-là. Donc, c'est une supposition folle, mais peut-être que Google a dû redémarrer son équilibreur de charge pour déployer une nouvelle version, un correctif, peu importe, c'est tout un logiciel après tout, donc le client (comme vu par Gunicorm) peut s'être déconnecté de manière hostile/non- manière attendue. Quoi qu'il en soit, Gunicorn devrait être résilient à toutes les situations du client.

Ignorer ENOTCONN semble correct, il a été envisagé de le faire directement dans certains modules de Python stdlib, pour certaines opérations : https://bugs.python.org/issue30319#msg297643

Même erreur.

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected

Deux applications de flacon (api et interface) dans des conteneurs docker séparés exécutant chacun gunicorn. L'erreur se produit dans Chrome/Chromium (pas Firefox), lorsque je publie sur l'API via un formulaire dans l'application d'interface. Il peut être connecté aux connexions TCP préemptives de Chrome . Puisque nginx devrait être capable de les gérer, je l'ai mis devant les conteneurs. Ne change rien.

@uree quel travailleur ? Comment lancez-vous gunicorn?

CMD ["gunicorn", " app:app ", "-b", "0.0.0.0:8001", "-t 90"]
j'ai aussi essayé
CMD ["gunicorn", " app:app ", "-b", "0.0.0.0:8001", "-t 90", "--preload"]

Je vois le même problème lors de l'exécution de django avec gunicorn avec docker-compose sur Digital Ocean.
Gunicorne version 20.0.4

version: '3.7'

services:
  backend:
    build: .
    command: gunicorn --workers=2 --thread=2 --log-file=- --certfile=/etc/nginx/ssl/xxx.crt --keyfile=/etc/nginx/ssl/xxx.key backend.config.wsgi:application --bind 0.0.0.0:8000
    restart: unless-stopped
    volumes:
      - .:/usr/src/app/
      - ../media:/backend/media
      - /root/certs/:/etc/nginx/ssl/
    ports:
      - 8000:8000
    env_file:
      - ./.env.dev
    environment:
      - Debug=True
      # - GUNICORN_WORKERS=2
      # - GUNICORN_ERRORLOG=-
      # - GUNICORN_THREADS=4
      # - GUNICORN_ACCESSLOG=-
    depends_on:
      - db
  db:
    image: postgres:12.0-alpine
    restart: unless-stopped
    volumes:
      - ../postgres_data:/var/lib/postgresql/data/
    environment:
      - POSTGRES_USER=xxxx
      - POSTGRES_PASSWORD=xxxx
      - POSTGRES_DB=archlink
  frontend:
    build: ./frontend
    volumes:
      - ./frontend:/app
      - /app/node_modules
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - BACKEND_URL=http://142.93.235.130:8000/
    depends_on:
      - backend
    # command: npm start
  nginx:
    image: nginx:latest
    restart: unless-stopped
    volumes:
      - ./nginx/nginx-proxy.conf:/etc/nginx/conf.d/default.conf:ro
      - ./frontend/build:/var/www/frontend # maps frontend build inside nginx
      - /root/certs/:/etc/nginx/ssl/
    ports:
      - 80:8080
      - 443:443
    depends_on:
      - frontend

Cette erreur se produit toutes les 4 à 5 minutes :

backend_1   | [2020-03-04 12:05:58 +0000] [18] [ERROR] Socket error processing request.
backend_1   | Traceback (most recent call last):
backend_1   |   File "/usr/local/lib/python3.8/site-packages/gunicorn/workers/gthread.py", line 266, in handle
backend_1   |     req = next(conn.parser)
backend_1   |   File "/usr/local/lib/python3.8/site-packages/gunicorn/http/parser.py", line 41, in __next__
backend_1   |     self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
backend_1   |   File "/usr/local/lib/python3.8/site-packages/gunicorn/http/message.py", line 186, in __init__
backend_1   |     super().__init__(cfg, unreader)
backend_1   |   File "/usr/local/lib/python3.8/site-packages/gunicorn/http/message.py", line 53, in __init__
backend_1   |     unused = self.parse(self.unreader)
backend_1   |   File "/usr/local/lib/python3.8/site-packages/gunicorn/http/message.py", line 198, in parse
backend_1   |     self.get_data(unreader, buf, stop=True)
backend_1   |   File "/usr/local/lib/python3.8/site-packages/gunicorn/http/message.py", line 189, in get_data
backend_1   |     data = unreader.read()
backend_1   |   File "/usr/local/lib/python3.8/site-packages/gunicorn/http/unreader.py", line 37, in read
backend_1   |     d = self.chunk()
backend_1   |   File "/usr/local/lib/python3.8/site-packages/gunicorn/http/unreader.py", line 64, in chunk
backend_1   |     return self.sock.recv(self.mxchunk)
backend_1   |   File "/usr/local/lib/python3.8/ssl.py", line 1226, in recv
backend_1   |     return self.read(buflen)
backend_1   |   File "/usr/local/lib/python3.8/ssl.py", line 1101, in read
backend_1   |     return self._sslobj.read(len)
backend_1   | OSError: [Errno 0] Error

Même erreur.

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected

Deux applications de flacon (api et interface) dans des conteneurs docker séparés exécutant chacun gunicorn. L'erreur se produit dans Chrome/Chromium (pas Firefox), lorsque je publie sur l'API via un formulaire dans l'application d'interface. Il peut être connecté aux connexions TCP préemptives de Chrome . Puisque nginx devrait être capable de les gérer, je l'ai mis devant les conteneurs. Ne change rien.

Mise à jour Dans mon cas, le problème était ailleurs. Cela a été causé par un événement jquery onclick sur un bouton de soumission. J'ai dû poster de manière asynchrone avec ajax pour résoudre le problème.

Y a-t-il des mises à jour sur cette erreur?

Y a-t-il des mises à jour sur cette erreur?

bien pouvez-vous décrire le contexte dans lequel cela se passe? Pour tout cela, en utilisant kubernetes, pouvez-vous décrire comment votre bilan de santé est configuré afin que nous puissions le reproduire ?

Qu'est-ce qui fait penser que c'est lié à Kubernetes ? Aucun client qui se comporte mal, une connexion à moitié fermée ne devrait jamais planter complètement un travailleur Gunicorn, qu'il s'exécute dans Kubernetes, Mesos, docker, baremetal : Gunicorn est le plus résilient.

Je n'ai pas trouvé de reproducteur fiable/facile, mais si je le fais, je pense que je pourrai peut-être faire planter tous les serveurs Web gunicorn directement exposés à Internet.

eh bien, je n'ai jamais eu un tel crash lorsque gunicorn est derrière nginx et certains émis
rapporté il semble lié à kubernetes.

Sur quel travailleur cela se passe-t-il ? Le gunicorn est-il utilisé derrière un proxy ? Lequel
une?

Le mar 10 mars 2020 à 11:52 Jordan Pittier [email protected] a écrit :

Qu'est-ce qui fait penser que c'est lié à Kubernetes ? Pas de client qui se conduit mal, la moitié
connexion fermée ne devrait jamais planter complètement un travailleur Gunicorn, que ce soit
ça tourne à Kubernetes, Mesos, docker, baremetal: Gunicorn most be
résilient.

Je n'ai pas trouvé de reproducteur fiable/facile, mais si je le fais, je pense que je peux être
capable de planter tous les serveurs Web de gunicorn directement exposés au
L'Internet.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/benoitc/gunicorn/issues/1913?email_source=notifications&email_token=AAADRITYFZI4GINCSG752OTRGYLXDA5CNFSM4GBYQQA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX2HJKLOOKTDN5 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAADRIRSO4T7WQTS6GMHLO3RGYLXDANCNFSM4GBYQQAQ
.

>

Envoyé depuis mon mobile

Même erreur avec un service aws ecs derrière un équilibreur de charge aws.
Arrivé une fois en même temps sur toutes les répliques (conteneurs/tâches)
Gunicorn comme paquet de pépins. Pas de Nginx, pas de proxy.
Python 3.7.6
Version Gunicorne : 20.0.4
Exécutez comme :
gunicorn --bind 0.0.0.0:8000 --workers 1 --threads 5 --max-requests 100 --timeout 300 application.wsgi
Enregistrer:
[2020-03-10 22:28:38 +0100] [105] [ERROR] Socket error processing request. Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 266, in handle req = next(conn.parser) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/parser.py", line 41, in __next__ 22:28:37.814 WARNING [django.request:log_response #228] Not Found: /443 22:28:36.176 WARNING [django.request:log_response #228] Not Found: /443 [2020-03-10 22:28:35 +0100] [105] [ERROR] Socket error processing request. Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 266, in handle req = next(conn.parser) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/parser.py", line 41, in __next__ self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 186, in __init__ super().__init__(cfg, unreader) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 53, in __init__ unused = self.parse(self.unreader) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 235, in parse self.headers = self.parse_headers(data[:idx]) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 73, in parse_headers remote_addr = self.unreader.sock.getpeername() OSError: [Errno 107] Transport endpoint is not connected [2020-03-10 22:28:35 +0100] [105] [ERROR] Socket error processing request. Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 266, in handle req = next(conn.parser) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/parser.py", line 41, in __next__ self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 186, in __init__ super().__init__(cfg, unreader) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 53, in __init__ unused = self.parse(self.unreader) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 235, in parse self.headers = self.parse_headers(data[:idx]) File "/usr/local/lib/python3.7/site-packages/gunicorn/http/message.py", line 73, in parse_headers remote_addr = self.unreader.sock.getpeername() OSError: [Errno 107] Transport endpoint is not connected

Y a-t-il des mises à jour sur cette erreur?

bien pouvez-vous décrire le contexte dans lequel cela se passe? Pour tout cela, en utilisant kubernetes, pouvez-vous décrire comment votre bilan de santé est configuré afin que nous puissions le reproduire ?

Je n'ai rien de précis. L'erreur survient de nulle part, aucune action notable ne se produit à l'origine de cette erreur.
Dans l'application django autre que les points de terminaison d'API REST standard, il existe un planificateur de travaux django. Tout le reste que vous pouvez voir dans le fichier docker-compose.yml.

Je peux fournir quelques données supplémentaires. Je vois cela de temps en temps avec gunicorn 19.9.0 exécuté derrière haproxy en tant que proxy inverse (en utilisant simplement HTTP, sans utiliser le protocole PROXY ).

Mar 17 21:38:07 redacted.com gunicorn[25470]: https://redacted.com/redacted[2020-03-17 21:38:07 +0000] [25495] [ERROR] Socket error processing request.
Mar 17 21:38:07 redacted.com gunicorn[25470]: Traceback (most recent call last):
Mar 17 21:38:07 redacted.com gunicorn[25470]:   File "/var/venvs/software-venv/lib/python3.6/site-packages/gunicorn/workers/sync.py", line 134, in handle
Mar 17 21:38:07 redacted.com gunicorn[25470]:     req = six.next(parser)
Mar 17 21:38:07 redacted.com gunicorn[25470]:   File "/var/venvs/software-venv/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
Mar 17 21:38:07 redacted.com gunicorn[25470]:     self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
Mar 17 21:38:07 redacted.com gunicorn[25470]:   File "/var/venvs/software-venv/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
Mar 17 21:38:07 redacted.com gunicorn[25470]:     super(Request, self).__init__(cfg, unreader)
Mar 17 21:38:07 redacted.com gunicorn[25470]:   File "/var/venvs/software-venv/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
Mar 17 21:38:07 redacted.com gunicorn[25470]:     unused = self.parse(self.unreader)
Mar 17 21:38:07 redacted.com gunicorn[25470]:   File "/var/venvs/software-venv/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
Mar 17 21:38:07 redacted.com gunicorn[25470]:     self.headers = self.parse_headers(data[:idx])
Mar 17 21:38:07 redacted.com gunicorn[25470]:   File "/var/venvs/software-venv/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
Mar 17 21:38:07 redacted.com gunicorn[25470]:     remote_addr = self.unreader.sock.getpeername()
Mar 17 21:38:07 redacted.com gunicorn[25470]: OSError: [Errno 107] Transport endpoint is not connected

Le serveur traitait environ 30 requêtes/seconde à l'époque. Comme vous pouvez le voir, la première ligne de journal a été mutilée, probablement en raison de la sortie en mémoire tampon et de plusieurs travailleurs.

Gunicorn est exécuté avec systemd : ExecStart=/var/venvs/software-venv/bin/gunicorn -b 0.0.0.0:6000 -w 4 app:app et LimitNOFILE=49152 .

J'ai envoyé une pull request avec un correctif que j'exécute en production depuis quelques jours maintenant. Le bogue est causé par une condition de concurrence, où le socket peut être fermé (par le client, le système d'exploitation, etc.) avant que getpeername() soit appelé, donc il lève correctement une exception. Cependant, gunicorn n'attrape pas cette exception, donc il bouillonne et plante le serveur. Mon correctif consiste simplement à intercepter l'exception et à la générer en tant qu'exception NoMoreData, qui est déjà gérée par un autre code plus haut dans la pile. Cela évite qu'une déconnexion au mauvais moment ne fasse planter le serveur.

Il y a aussi ce PR https://github.com/benoitc/gunicorn/pull/2277

J'utilise Kubernetes (1.16.8-gke.15) et le dernier Gunicorn (20.0.4) et Python 3.7. Si je fais une requête POST et que j'augmente un délai commençant par 1 seconde pour chaque itération, il cesse de fonctionner lorsque le délai est de 360 ​​secondes. Le travail à l'intérieur de Gunicorn est terminé et quelques minutes plus tard, il renvoie cette erreur :

Socket error processing request.
OSError: [Errno 107] Transport endpoint is not connected

Lorsque la connexion est interrompue entre Kubernetes et Gunicorn, le point de terminaison Kubernetes et le client sont toujours connectés. Les vérifications d'état semblent bonnes, mais il est possible qu'elles soient mal configurées d'une manière ou d'une autre. Je n'ai trouvé aucun journal du côté de Kubernetes pour identifier le problème.

J'ai eu le même résultat pour Gunicorn (19.7.1).

J'ai ajouté l'indicateur de délai d'attente pour Gunicorn et j'utilise l'équilibreur de charge GKE par défaut avec BackendConfig pour Kubernetes GKE . J'ai également essayé avec une entrée NGINX et en ajoutant des annotations pour gérer les délais d'attente. Commande de la licorne :

gunicorn --bind="0.0.0.0:5000" --workers=1 --timeout=1200 --keep-alive=1200 main:app

Lorsque je lance Gunicorn localement sans rien devant, cela fonctionne bien. Cela pourrait être plus un problème Kubernetes , cependant, la réponse est perdue.

Quelqu'un a-t-il eu de la chance avec ce problème? Ou un bon moyen de le déboguer ?

Docker version 19.03.8, build afacb8b7f0

Python 3.8.2 (par défaut, 26 février 2020, 15:09:34)
[GCC 8.3.0] sur Linux

import multiprocessing
import os

bind = '0.0.0.0:8889'
max_requests = 100000
timeout = 60
graceful_timeout = 60
if os.environ.get('WEB_WORKERS') is None:
    _cpu_count = multiprocessing.cpu_count()
    workers = 2 * _cpu_count + 1
else:
    workers = int(os.environ['WEB_WORKERS'])
limit_request_line = 4094 * 4  # 4x then default val
errorlog = '/var/log/krapi/gunicorn.error.log'
accesslog = '/var/log/krapi/gunicorn.access.log'

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/gunicorn/workers/sync.py", line 133, in handle
    req = next(parser)
  File "/usr/local/lib/python3.8/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.8/site-packages/gunicorn/http/message.py", line 186, in __init__
    super().__init__(cfg, unreader)
  File "/usr/local/lib/python3.8/site-packages/gunicorn/http/message.py", line 53, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.8/site-packages/gunicorn/http/message.py", line 235, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/usr/local/lib/python3.8/site-packages/gunicorn/http/message.py", line 73, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected

Dans mon cas, j'ai découvert que toute requête HEAD émettait ceci.

J'utilise django derrière gunicorn et je soupçonne que l'application souhaite écrire un corps de réponse (cela ne devrait pas), mais je n'ai pas encore confirmé que ce soit le cas.

même comportement

Je pense que cela pourrait être corrigé par #2277

Dans mon cas, le module wait_for d'Ansible en est la cause.

J'utilise Ansible pour déployer un serveur gunicorn + flask (en particulier Python 3.6.12, gunicorn 19.9.0, Flask 1.4.1).

Après avoir démarré le service, j'utilise le module wait_for pour m'assurer que le service est opérationnel.
Ce module interrompt probablement la connexion immédiatement après avoir validé le service (sans attendre la réponse de gunicorn) et ainsi, gunicorn génère cette erreur.

Je suppose que d'autres systèmes de surveillance font de même.

J'ai la même erreur .. hmm
Actuellement, nous avons un trafic énorme. 100-1000 TPS, et certaines requêtes ont échoué de manière aléatoire

Python 3.8
Ballon
Gunicorne

Avec les propriétés de docker ci-dessous.

FROM python:3-slim

RUN apt-get update && apt-get -y install gcc

ENV PYTHONUNBUFFERED True

COPY . /app

WORKDIR /app/src

RUN pip install Flask requests gunicorn
RUN pip install -U flask-cors
RUN pip install requests
RUN pip install DateTime
RUN pip install timedelta

RUN chmod 444 app.py

CMD exec gunicorn -b :443 --workers 5 --threads 8 --timeout 10 app:app --reload

Toute solution?

Y a-t-il des mises à jour à ce sujet ?
Il semble qu'il y ait plusieurs PR pour le corriger, avons-nous un délai pour les publier ?

Salut @tilgovi
Avons-nous un calendrier pour sortir cette nouvelle version ? il semble que le package Gunicorn ne se mette pas à jour depuis longtemps...

Je ferai une sortie probablement aujourd'hui. Je vais revérifier ce problème enotconn car je ne suis pas satisfait de la solution engagée. @tilgovi a un autre correctif qui peut être testé.

?

as-tu testé l'autre patch pour t'aider ?

merci, je me demande s'il y a des informations de mise à jour sur le paquet pip?

@yehjames est le maître qui travaille pour vous ? Une sortie est prévue dès aujourd'hui. Mais tout commentaire sur le fonctionnement de master sur différentes plateformes est le bienvenu.

@benoitc Une mise à jour à ce sujet? Utilisation de 20.0.4 en production et mise en œuvre du changement suggéré par @asantoni (sous forme de patch singe) pour éviter les plantages fréquents. Mais l'analyse de code statique Veracode n'aime pas le correctif, alors essayez de le corriger maintenant. Merci!

Nous travaillerons pour sortir une version dès que possible. Nous ne pouvons pas promettre un jour, mais nous travaillons pour comprendre ce qui reste pour cette version et pour améliorer la gestion des versions pour l'avenir.

Veuillez utiliser la fonction "Watch" de GitHub pour le référentiel et surveiller les versions si vous souhaitez être averti.

Salut. J'ai le même problème avec HAProxy + Gunicorn + Django.

Mon backend HAProxy perd presque tous ses serveurs en raison de contrôles non répondus et les journaux Gunicorn sont en proie à :

[2021-07-23 18:16:27 -0500] [13] [ERROR] Socket error processing request. Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/sync.py", line 133, in handle req = next(parser) File "/usr/local/lib/python3.9/site-packages/gunicorn/http/parser.py", line 41, in __next__ self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count) File "/usr/local/lib/python3.9/site-packages/gunicorn/http/message.py", line 186, in __init__ super().__init__(cfg, unreader) File "/usr/local/lib/python3.9/site-packages/gunicorn/http/message.py", line 53, in __init__ unused = self.parse(self.unreader) File "/usr/local/lib/python3.9/site-packages/gunicorn/http/message.py", line 235, in parse self.headers = self.parse_headers(data[:idx]) File "/usr/local/lib/python3.9/site-packages/gunicorn/http/message.py", line 73, in parse_headers remote_addr = self.unreader.sock.getpeername() OSError: [Errno 107] Transport endpoint is not connected

Je travaille avec gunicorn==20.0.4, Django==3.1.5, HA-Proxy version 2.2.11-1ppa1~bionic

Une idée sur la marche à suivre ?

C'est en mode TCP, pas de SSL, en test de stress acridien.

Quelqu'un s'il vous plaît partager la solution sur ce problème

@krishnamanchikalapudi @ricarhincapie s'il vous plaît mettre à niveau vers la dernière version de Gunicorn :)