Gunicorn: Enchufes

¿Hay algo interesante aguas arriba de gunicorn en su pod, como un proxy inverso, nginx?

No, sin proxies, sin nginx

Tengo exactamente el mismo problema: confundido:

Upstream tenemos HAProxy y en su formato de registro HTTP, el estado de la sesión en la desconexión (consulte http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#8.5) registra esos errores como CH-- significado:

• C: el cliente anuló inesperadamente la sesión de TCP.
• H: el proxy estaba esperando una respuesta completa y válida HEADERS del servidor (solo HTTP).

Entonces, si lo entiendo correctamente, el cliente cerró la conexión mientras Gunicorn todavía estaba enviando la respuesta.

¿Alguna pista de qué hace que el cliente aborte? ¿Estuvo esperando mucho tiempo para que gunicorn enviara encabezados de respuesta completos?

@javabrett no lo parece, al menos en los pocos mensajes de registro que busqué, en su mayoría son imágenes u otros activos, por lo que no debería tomar mucho tiempo.

¿El cliente podría haber cerrado el navegador o cualquier otra acción que cerrara abruptamente la conexión? :pensando:

@gforcada ¿estás usando el protocolo proxy con haproxy?

@benoitc no que yo sepa

alguien llega a alguna parte con esto? No tengo mucho que aportar excepto el mismo error exacto.

Mi configuración consiste en un balanceador de carga que se usa para terminar SSL y reenviar solicitudes a una aplicación de django que se ejecuta en un contenedor de Docker. No estoy seguro de con qué se implementa el LB: es un producto de Digital Ocean.

Estoy bastante seguro de que está relacionado con el equilibrador de carga porque tengo la misma aplicación ejecutándose en otro contenedor que no está detrás de un LB y nunca ha tenido este problema.

¿Alguna idea sobre la causa raíz y cómo prevenirla?

Me pregunto si hay alguna acción aquí. Si se trata de una desconexión regular del cliente, tal vez podríamos silenciar el error y tal vez registrar una desconexión en el registro de acceso, pero de lo contrario no estoy seguro de qué hacer.

Acabo de tener el mismo error que bloqueó nuestro servidor web de monitoreo:

[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)

Tuve lo mismo con el pod ejecutando la imagen de la ventana acoplable dpage / pgadmin4: 4.2

OSError: [Errno 107] Socket no conectado
[2019-06-14 12:20:32 +0000] [77] [ERROR] Solicitud de procesamiento de error de socket.
Rastreo (llamadas recientes más última):
Archivo "/usr/local/lib/python3.6/site-packages/gunicorn/workers/gthread.py", línea 274, en el identificador
req = seis.siguiente (analizador de conexiones)
Archivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", línea 41, en __next__
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Archivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", línea 181, en __init__
super (Request, self) .__ init __ (cfg, unreader)
Archivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", línea 54, en __init__
no utilizado = self.parse (self.unreader)
Archivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", línea 230, en análisis
self.headers = self.parse_headers (datos [: idx])
Archivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", línea 74, en parse_headers
remote_addr = self.unreader.sock.getpeername ()

Parece muy similar a: https://github.com/benoitc/gunicorn/issues/2070

Recibo este error ocasionalmente en Google Cloud Run alojado. A continuación se muestra una versión simplificada de nuestra definición de contenedor:

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 muestra el siguiente seguimiento de pila:

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

El mismo problema que OP aquí. Con 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"

Estoy teniendo exactamente el mismo problema 😕

Exactamente el mismo problema que GAEfan. Ejecución de una aplicación Flask con Python 3.7 en App Engine Standard Env.

El mismo problema aquí

Tengo el mismo problema al ejecutar la aplicación Django con Python 3.7 en Google App Engine.

Traceback (última llamada más reciente): Archivo "/env/lib/python3.7/site-packages/gunicorn/workers/sync.py", línea 134, en el identificador req = six.next (analizador) Archivo "/ env / lib / python3.7 / site-packages / gunicorn / http / parser.py ", línea 41, en __next__ self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count) Archivo" / env / lib /python3.7/site-packages/gunicorn/http/message.py ", línea 181, en __init__ super (Request, self) .__ init __ (cfg, unreader) File" /env/lib/python3.7/site-packages /gunicorn/http/message.py ", línea 54, en __init__ unused = self.parse (self.unreader) Archivo" /env/lib/python3.7/site-packages/gunicorn/http/message.py ", línea 230, en parse self.headers = self.parse_headers (data [: idx]) Archivo "/env/lib/python3.7/site-packages/gunicorn/http/message.py", línea 74, en parse_headers remote_addr = self .unreader.sock.getpeername () OSError: [Errno 107] El punto final de transporte no está conectado

El mismo problema al ejecutar GAE python 3.7 gunicorn y fastapi / uvicorn.

Mismo problema Google Cloud Run

¿De qué tipo de solicitud estamos hablando?

mismo problema en el motor de aplicaciones de Google. Solicitud POST. sucede de manera inconsistente. Aplicación de matraz. @benoitc por favor déjeme saber qué información sería útil y puedo publicar.

El mismo problema también, Google App Engine, solicitud POST también, aplicación Flask. Parecía haber comenzado cuando cambié a un código de punto de entrada personalizado en lugar de dejar el predeterminado. El punto de entrada personalizado es el siguiente (en Google App Engine, lo configura dentro de un archivo app.yaml):

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

El punto de entrada predeterminado no establece nada (aunque no sé qué se usa como punto de entrada predeterminado).

No estoy seguro de si comenzó debido a eso, pero lo noté cuando hice este cambio (entre otros cambios).

No, sin proxies, sin nginx

Estaba usando gunicorn sin nginx . Estaba teniendo el mismo problema. Mi configuración se ejecuta en 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

el soporte de la pregunta

El mismo problema también, Google App Engine, solicitud POST también, aplicación Flask. Parecía haber comenzado cuando cambié a un código de punto de entrada personalizado en lugar de dejar el predeterminado. El punto de entrada personalizado es el siguiente (en Google App Engine, lo configura dentro de un archivo app.yaml):

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

El punto de entrada predeterminado no establece nada (aunque no sé qué se usa como punto de entrada predeterminado).

No estoy seguro de si comenzó debido a eso, pero lo noté cuando hice este cambio (entre otros cambios).

¿A qué te refieres con punto de entrada? ¿Puede publicar un registro de depuración y la forma en que se realiza la solicitud? (http sin formato ayudaría)

el soporte de la pregunta

El mismo problema también, Google App Engine, solicitud POST también, aplicación Flask. Parecía haber comenzado cuando cambié a un código de punto de entrada personalizado en lugar de dejar el predeterminado. El punto de entrada personalizado es el siguiente (en Google App Engine, lo configura dentro de un archivo app.yaml):
gunicorn -b :$PORT --timeout 1200 server.main:app
El punto de entrada predeterminado no establece nada (aunque no sé qué se usa como punto de entrada predeterminado).
No estoy seguro de si comenzó debido a eso, pero lo noté cuando hice este cambio (entre otros cambios).

¿A qué te refieres con punto de entrada? ¿Puede publicar un registro de depuración y la forma en que se realiza la solicitud? (http sin formato ayudaría)

Creo que se refiere al hecho de que estás especificando explícitamente la ruta app que el _gunicorn_ debería importar-buscar y ejecutar, como server.main:app en su ejemplo.

LE: Tal vez el ejemplo actualizado aquí ayude: https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/standard_python37/hello_world (así que básicamente tienes que dejar que el servicio maneje cómo debería ser el servidor empezado)

En primer lugar, @benoitc GRACIAS. Tu trabajo es asombroso.

También estoy experimentando este mismo problema en Google Cloud Run con gunicorn. Estoy publicando lo que tengo, aunque probablemente no sea único, examinando lo anterior. Estoy ejecutando una aplicación Flask con Gunicorn como servidor (y sin proxy) en un contenedor Docker.

El rastreo (desde la consola de 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

Y el resultado analizado de Google de lo anterior:

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)

Si hay algo más que pueda proporcionar o hacer para ayudar aquí, hágamelo saber.

Un PR sería bienvenido para manejar ENOTCONN gracia para todos los trabajadores. Publique aquí si comienza a trabajar en esto y me complacerá revisar un PR. Estoy seguro de que algunos en este hilo estarían encantados de ayudar a probar una rama.

El mismo problema, Google App Engine, gunicorn sirviendo una aplicación Django, un pequeño porcentaje de solicitudes mueren así:

entrypoint: gunicorn -b :$PORT wsgi_api:application

Un PR sería bienvenido para manejar ENOTCONN gracia para todos los trabajadores. Publique aquí si comienza a trabajar en esto y me complacerá revisar un PR. Estoy seguro de que algunos en este hilo estarían encantados de ayudar a probar una rama.

Soy uno de los que están en este hilo y estoy feliz de ayudar en la prueba, así que por favor envíeme un ping si puedo ayudar.

Un PR sería bienvenido para manejar ENOTCONN gracia para todos los trabajadores. Publique aquí si comienza a trabajar en esto y me complacerá revisar un PR. Estoy seguro de que algunos en este hilo estarían encantados de ayudar a probar una rama.

Soy uno de los que están en este hilo y estoy feliz de ayudar en la prueba, así que por favor envíeme un ping si puedo ayudar.

Estoy feliz de ayudar a probar las relaciones públicas. Si necesita ayuda, por favor envíeme un mensaje.

Estoy feliz de ayudar a probar las relaciones públicas. Si necesita ayuda, por favor envíeme un mensaje.

Un PR sería bienvenido para manejar ENOTCONN gracia para todos los trabajadores. Publique aquí si comienza a trabajar en esto y me complacerá revisar un PR. Estoy seguro de que algunos en este hilo estarían encantados de ayudar a probar una rama.

La causa raíz de este problema con la última versión de gunicorn==19.9.0 . Me cambiaron para usar la versión anterior de gunicorn==19.7.1 . Pude correr sin ningún problema. Inténtelo con la versión anterior.

mejor prueba el último maestro. 20.0 finalmente llegará hoy. Me han desviado.

¿Cómo se ve su punto final de control de salud? ¿Cómo respondes? ¿Estás cerrando la conexión? ¿Establece encabezado de longitud y co? No estoy seguro de por qué se realiza una verificación de estado por correo postal. suena raro...

@ cmin764 ¿fflask establece algún encabezado predeterminado? Lo intentaré, pero sería interesante saber que la respuesta parece

@benoitc Cuando estaba usando la comprobación de estado del punto final gunicorn==19.9.0 es realmente mala. Las conexiones a la base de datos están esperando por más tiempo. La carga completa de la aplicación se cae.

más antiguo gunicorn==19.7.1 punto final está rompiendo La comprobación del estado del punto final se ve bien. No estaba cerrando ninguna conexión y no establecía la longitud de los encabezados.

También probaré la última versión 20.0.

No, sin proxies, sin nginx

Estaba usando gunicorn sin nginx . Estaba teniendo el mismo problema. Mi configuración se ejecuta en 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

con la versión anterior gunicorn = 19.7.1 I was not able to run with the gevent`. He cambiado mi comando gunicorn

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

Estoy mirando los cambios desde esta versión para ver si hay alguna razón para ello. ¡Gracias por la respuesta!

El uso de 19.7.1 (degradación desde la más reciente) funcionó en el entorno del motor de aplicaciones de Google con colas de inserción que alimentan a los trabajadores y los trabajadores se comunican entre sí a través de http.

El uso de 19.7.1 (degradación desde la más reciente) funcionó en el entorno del motor de aplicaciones de Google con colas de inserción que alimentan a los trabajadores y los trabajadores se comunican entre sí a través de http.

Este es mi caso de uso. Le daré una oportunidad a esto.

¿Probaste la última versión?

Probé el último 20.0.0 en Openshift (openshift v3.11.135, kubernetes v1.11.0); se produce el mismo error. El error que observé se activa en una carga más alta (pruebas de integración que ejecutan 20 trabajadores paralelos). Aumentar el número de pods reduce la aparición de errores, lo que deja como resultado un único pod en un error garantizado. Es la configuración de 3 trabajadores de sincronización. 19.7.1 simplemente no muestra ningún error en los registros de pod , pero el consumidor externo experimenta el mismo EOF inesperado en la conexión como con la versión más reciente. Así que la versión degradante no ayuda.

2019-11-12 16: 08: 56,982 ERROR gunicorn.error glogging 277 glogging.py Solicitud de procesamiento de error de socket.
Rastreo (llamadas recientes más última):
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", línea
134, en mango
req = six.next (analizador)
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", línea 41, en __next__
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", línea 181, en __init__
super (Request, self) .__ init __ (cfg, unreader)
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", línea 54, en __init__
no utilizado = self.parse (self.unreader)
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", línea 230, en parse
self.headers = self.parse_headers (datos [: idx])
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", línea 74, en parse_headers
remote_addr = self.unreader.sock.getpeername ()
OSError: [Errno 107] El punto final de transporte no está conectado

Probé el último 20.0.0 en Openshift (openshift v3.11.135, kubernetes v1.11.0); se produce el mismo error. El error que observé se activa en una carga más alta (pruebas de integración que ejecutan 20 trabajadores paralelos). Aumentar el número de pods reduce la aparición de errores, lo que deja como resultado un único pod en un error garantizado. Es la configuración de 3 trabajadores de sincronización. 19.7.1 simplemente no muestra ningún error en los registros de pod , pero el consumidor externo experimenta el mismo EOF inesperado en la conexión como con la versión más reciente. Así que la versión degradante no ayuda.

2019-11-12 16: 08: 56,982 ERROR gunicorn.error glogging 277 glogging.py Solicitud de procesamiento de error de socket.
Rastreo (llamadas recientes más última):
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", línea
134, en mango
req = six.next (analizador)
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", línea 41, en la siguiente
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", línea 181, en init
super (Solicitud, yo). init (cfg, unreader)
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", línea 54, en init
no utilizado = self.parse (self.unreader)
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", línea 230, en parse
self.headers = self.parse_headers (datos [: idx])
Archivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", línea 74, en parse_headers
remote_addr = self.unreader.sock.getpeername ()
OSError: [Errno 107] El punto final de transporte no está conectado

¿Puede intentar aumentar el tiempo de espera del enrutador?

¿Puede intentar aumentar el tiempo de espera del enrutador?

Siguiendo este ejemplo, encontramos un problema : la configuración de la sonda de preparación de Openshift era demasiado optimista (la aplicación tardaba demasiado para algunas solicitudes) y, en caso de falla, el equilibrador de carga externo (AVI) recogió este evento y expulsó al pod del grupo de equilibrio de carga.

Recientemente experimenté este problema con gunicorn = 19.9.0. Un reinicio resolvió el problema. Estoy implementado en Google Kubernetes Engine. La aplicación es una aplicación de matraz -
entrada:
command: ["sh", "-c", "gunicorn -b 0.0.0.0:$${PORT} -c gunicorn_config.py run:app"]
config:

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

Error:
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 solución actual es degradar a 19.7.1 ?

¿Alguien puede compartir un repositorio con instrucciones de implementación que pueda usar para reproducir el problema? Estoy feliz de investigarlo, pero quiero asegurarme de saber exactamente cómo configurarlo.

Hola @tilgovi Fastapi usa gunicorn en producción.
Este repositorio tiene una versión mínima y mostró el mismo error. Puedes intentarlo, he tenido este error en App Engine, no sé si se replica con otros entornos. Ese repositorio, ¿podría ayudar a reproducir el problema?

Mismo problema aquí:
gunicorn 19.9.0 + GKE también se produjo cuando se trataba de una carga alta.

cmin

No estoy seguro, pero todo parece volver a la normalidad ahora.

Esta es mi aplicación.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

Y corrida de producción 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

Entonces, tal vez fue algo temporal en GAE.

Tengo el mismo problema. Gunicorn con gevent, solo un LB HTTP de Google al frente. (sin Nginx u otro proxy inverso). Las cosas funcionan bien durante semanas, pero de vez en cuando obtengo:

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

Gunicorn 20.0.4.

El hecho de que varias personas informaron que su "pasa con mucha carga" o que, en mi caso, esto pasa "unas cuantas veces al mes" parece que se trata de una especie de condición de carrera.

@JordanP fo tiene algún error en el lado de Google? ¿Cómo se envía el ping desde Google LB? ¿Se agota el tiempo de espera en el lado de Google LB?

Se está ejecutando en Kubernetes, la verificación de estado es HTTP, muy conservadora (tiempo de espera de 5 segundos, 10 fallas consecutivas antes de marcar los contenedores como muertos).

En el lado de Google, el HTTP LB frente a Gunicorn devolvió más de 40k 502 errores (en un par de minutos) con la siguiente razón: "backend_timeout":

Obtuve 4 réplicas (4 contenedores), todos se estrellaron a la misma hora esa noche. Entonces, es una suposición descabellada, pero tal vez Google tuvo que reiniciar su equilibrador de carga para implementar una nueva versión, una solución, lo que sea, todo es software después de todo, por lo que el cliente (como lo vio Gunicorm) puede haberse desconectado de una manera hostil / no- manera esperada. De cualquier forma, Gunicorn debería ser resistente a cualquier situación que suceda con el cliente.

Ignorar ENOTCONN parece correcto, se discutió hacerlo directamente en algunos módulos de la biblioteca estándar de Python, para algunas operaciones: https://bugs.python.org/issue30319#msg297643

Mismo error.

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

Dos aplicaciones de matraces (api e interfaz) en contenedores acoplables separados, cada uno con gunicorn. El error ocurre en Chrome / Chromium (no en Firefox), cuando publico en la API a través de un formulario en la aplicación de interfaz. Podría estar conectado a las conexiones TCP preventivas de Chrome. Como nginx debería poder manejarlos, lo he puesto delante de los contenedores. No cambia nada.

@uree que trabajador? ¿Cómo lanzas gunicorn?

CMD ["gunicorn", " aplicación: aplicación ", "-b", "0.0.0.0:8001", "-t 90"]
Yo tambien lo he intentado
CMD ["gunicorn", " app: app ", "-b", "0.0.0.0:8001", "-t 90", "--preload"]

Veo el mismo problema al ejecutar django con gunicorn con docker-compose en Digital Ocean.
Gunicorn versión 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

Este error ocurre cada 4-5 minutos:

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

Mismo error.

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

Dos aplicaciones de matraces (api e interfaz) en contenedores acoplables separados, cada uno con gunicorn. El error ocurre en Chrome / Chromium (no en Firefox), cuando publico en la API a través de un formulario en la aplicación de interfaz. Podría estar conectado a las conexiones TCP preventivas de Chrome. Como nginx debería poder manejarlos, lo he puesto delante de los contenedores. No cambia nada.

Actualización En mi caso, el problema estaba en otra parte. Fue causado por un evento jquery onclick en un botón de envío. Tuve que publicar de forma asincrónica con ajax para resolver el problema.

¿Hay actualizaciones sobre este error?

¿Hay actualizaciones sobre este error?

bien, ¿puede describir el contexto en el que está sucediendo? Además, para todo el uso de esos kubernetes, ¿puede describir cómo se configura su verificación de salud para que podamos reproducirla?

¿Qué te hace pensar que está relacionado con Kubernetes? Ningún cliente que se comporte mal, la conexión medio cerrada debería bloquear por completo a un trabajador de Gunicorn, ya sea que se esté ejecutando en Kubernetes, Mesos, docker, baremetal: Gunicorn es más resistente.

No he encontrado un reproductor confiable / fácil, pero si lo hago, creo que podría bloquear todos los servidores web de Gunicorn directamente expuestos a Internet.

bueno, nunca tuve tal accidente cuando gunicorn está detrás de nginx y algunos emitieron
informó que parece estar relacionado con kubernetes.

¿A qué trabajador le está sucediendo? ¿Se usa gunicorn detrás de un proxy? Cuales
¿uno?

El martes 10 de marzo de 2020 a las 11:52, Jordan Pittier [email protected] escribió:

¿Qué te hace pensar que está relacionado con Kubernetes? Ningún cliente portándose mal, la mitad
La conexión cerrada debería bloquear por completo a un trabajador de Gunicorn, ya sea
se está ejecutando en Kubernetes, Mesos, docker, baremetal: Gunicorn
elástico.

No he encontrado un reproductor confiable / fácil, pero si lo encuentro, creo que podría ser
capaz de bloquear todos los servidores web gunicorn expuestos directamente a la
Internet.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/benoitc/gunicorn/issues/1913?email_source=notifications&email_token=AAADRITYFZI4GINCSG752OTRGYLXDA5CNFSM4GBYQQA2YY3PNVWWK3TUL52HS4DFVREXG43VMDVN5W63 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAADRIRSO4T7WQTS6GMHLO3RGYLXDANCNFSM4GBYQQAQ
.

>

Enviado desde mi móvil

El mismo error con un servicio de aws ecs detrás de un balanceador de carga de aws.
Ocurrió una vez al mismo tiempo en todas las réplicas (contenedores / tareas)
Gunicorn como paquete de pepitas. Sin Nginx, sin proxy.
Python 3.7.6
Versión Gunicorn: 20.0.4
Corre como:
gunicorn --bind 0.0.0.0:8000 --workers 1 --threads 5 --max-requests 100 --timeout 300 application.wsgi
Tronco:
[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

¿Hay actualizaciones sobre este error?

bien, ¿puede describir el contexto en el que está sucediendo? Además, para todo el uso de esos kubernetes, ¿puede describir cómo se configura su verificación de salud para que podamos reproducirla?

No tengo nada específico. El error ocurre de la nada, no ocurren acciones notables que causen este error.
En la aplicación de django, además de los puntos finales regulares de la API REST, hay un programador de trabajos de django. Todo lo demás se puede ver en docker-compose.yml.

Puedo proporcionar más datos. Veo esto ocasionalmente con gunicorn 19.9.0 ejecutándose detrás de haproxy como un proxy inverso (solo usando HTTP, no usando el protocolo 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

El servidor estaba manejando alrededor de 30 solicitudes / segundo en ese momento. Como puede ver, la primera línea de registro se estropeó, presumiblemente debido a la salida almacenada en búfer y a varios trabajadores.

Gunicorn se ejecuta con systemd: ExecStart=/var/venvs/software-venv/bin/gunicorn -b 0.0.0.0:6000 -w 4 app:app y LimitNOFILE=49152 .

Envié una solicitud de extracción con una solución que he estado ejecutando en producción durante unos días. El error es causado por una condición de carrera, donde el socket puede ser cerrado (ya sea por cliente, sistema operativo, etc.) antes de que se llame a getpeername() , por lo que genera correctamente una excepción. Sin embargo, gunicorn no detecta esta excepción, por lo que está burbujeando y bloqueando el servidor. Mi solución es solo detectar la excepción y plantearla como una excepción NoMoreData, que ya está manejada por otro código más arriba en la pila. Esto evita que una desconexión en el momento oportuno bloquee el servidor.

También está este PR https://github.com/benoitc/gunicorn/pull/2277

Estoy usando Kubernetes (1.16.8-gke.15) y el último Gunicorn (20.0.4), y Python 3.7. Si hago una solicitud POST y aumento un retraso de tiempo comenzando con 1 segundo para cada iteración, deja de funcionar cuando el retraso es de 360 ​​segundos. El trabajo dentro de Gunicorn está terminado, y unos minutos después devuelve este error:

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

Cuando la conexión se interrumpe entre Kubernetes y Gunicorn, el punto final de Kubernetes y el cliente todavía están conectados. Los controles de estado se ven bien, pero es posible que estén mal configurados de alguna manera. No he encontrado ningún registro en el lado de Kubernetes para identificar el problema.

Tuve el mismo resultado para Gunicorn (19.7.1).

Agregué la marca de tiempo de espera para Gunicorn y estoy usando el balanceador de carga de GKE predeterminado con BackendConfig para Kubernetes GKE . También probé con un NGINX Ingress y agregué anotaciones para manejar los tiempos de espera. Comando de Gunicorn:

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

Cuando ejecuto Gunicorn localmente sin nada frente a él, funciona bien. Esto podría ser más un problema de Kubernetes , sin embargo, la respuesta se pierde.

¿Alguien ha tenido suerte con este problema? ¿O una buena forma de depurarlo?

Docker versión 19.03.8, compilación afacb8b7f0

Python 3.8.2 (predeterminado, 26 de febrero de 2020, 15:09:34)
[GCC 8.3.0] en 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

En mi caso, descubrí que cualquier solicitud HEAD emite esto.

Estoy usando django detrás de gunicorn, y sospecho que la aplicación quiere escribir un cuerpo de respuesta (no debería), pero aún no he confirmado que ese sea el caso.

mismo comportamiento

Creo que esto podría solucionarse con el n. ° 2277

En mi caso, el módulo wait_for de Ansible es la causa.

Utilizo Ansible para implementar un servidor gunicorn + flask (específicamente Python 3.6.12, gunicorn 19.9.0, Flask 1.4.1).

Después de iniciar el servicio, uso el módulo wait_for para asegurarme de que el servicio esté en funcionamiento.
Este módulo probablemente interrumpe la conexión inmediatamente después de que valida que el servicio está activo (sin esperar a que gunicorn responda) y, por lo tanto, gunicorn genera este error.

Supongo que otros sistemas de monitoreo hacen lo mismo.

Tengo el mismo error ... hmm
Actualmente tenemos un gran tráfico ... 100-1000 TPS, y algunas solicitudes fallaron aleatoriamente

Python 3.8
Matraz
Gunicorn

Con las siguientes propiedades de la ventana acoplable ...

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

¿Alguna solución?

¿Hay alguna actualización sobre esto?
Parece que hay varios RP para solucionarlo, ¿tenemos una línea de tiempo para publicarlos?

Hola @tilgovi
¿Tenemos una línea de tiempo para lanzar esta nueva versión? parece que el paquete Gunicorn no se actualiza durante mucho tiempo ...

Probablemente haré un lanzamiento hoy. Volveré a comprobar este problema de enotconn ya que no estoy satisfecho con la solución comprometida. @tilgovi tiene otra solución que se puede probar.

?

¿Probaste el otro parche para ayudar?

gracias, me pregunto si hay alguna información actualizada sobre el paquete pip.

@yehjames, ¿el maestro trabaja para ti? Un lanzamiento está planeado ahora hoy. Pero cualquier comentario sobre cómo funciona Master en diferentes plataformas es bienvenido.

@benoitc ¿ Alguna actualización sobre esto? Usando 20.0.4 en producción e implementado el cambio sugerido por @asantoni (como parche de mono) para evitar fallas frecuentes. Pero el escaneo de código estático de Veracode no le gusta el parche, así que trato de arreglarlo ahora. ¡Gracias!

Trabajaremos para publicar un comunicado tan pronto como podamos. No podemos prometer un día, pero estamos trabajando para averiguar qué queda para esta versión y mejorar la gestión de versiones para el futuro.

Utilice la función "Ver" de GitHub para el repositorio y esté atento a las versiones si desea recibir una notificación.

Hola. Estoy teniendo el mismo problema con HAProxy + Gunicorn + Django.

Mi backend HAProxy pierde casi todos sus servidores debido a que las verificaciones no respondieron y los registros de Gunicorn están plagados de:

[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

Estoy trabajando con gunicorn == 20.0.4, Django == 3.1.5, HA-Proxy versión 2.2.11-1ppa1 ~ bionic

¿Alguna pista sobre cómo proceder?

Esto está en modo TCP, sin SSL, en pruebas de estrés por langosta.

Alguien por favor comparte la solución sobre este problema.

@krishnamanchikalapudi @ricarhincapie , actualice a la última versión de Gunicorn :)