Gunicorn: tomadas

Há algo interessante acima do gunicorn em seu pod, como um proxy reverso, nginx?

Não, sem proxies, sem nginx

Estou tendo exatamente o mesmo problema: confused:

Acima, temos o HAProxy e em seu formato de registro HTTP, o estado da sessão na desconexão (consulte http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#8.5) ele registra esses erros como CH-- significando:

• C: a sessão TCP foi abortada inesperadamente pelo cliente.
• H: o proxy estava esperando por HEADERS de resposta válidos e completos do servidor (apenas HTTP).

Então, se entendi bem, o cliente fechou a conexão enquanto o gunicorn ainda estava enviando a resposta.

Alguma pista sobre o que faz o cliente abortar? Demorou muito para o gunicorn enviar cabeçalhos de resposta completos?

@javabrett não parece assim, pelo menos nas poucas mensagens de log que

O cliente pode ter fechado o navegador ou qualquer outra ação que fecharia abruptamente a conexão? :pensamento:

@gforcada você está usando o protocolo de proxy com haproxy?

@benoitc que eu não saiba

Alguém consegue chegar a algum lugar com isso? Não tenho muito a contribuir, exceto exatamente o mesmo erro.

Minha configuração consiste em um balanceador de carga que está sendo usado para encerrar SSL e encaminhar solicitações para um aplicativo django em execução em um contêiner docker. Não tenho certeza com o que o LB é implementado - é um produto Digital Ocean.

Tenho quase certeza de que está relacionado ao balanceador de carga porque tenho o mesmo aplicativo em execução em outro contêiner que não está atrás de um LB e nunca teve esse problema.

Alguma ideia sobre a causa raiz e como prevenir?

Eu me pergunto se há alguma ação aqui. Se esta for uma desconexão normal do cliente, poderíamos silenciar o erro e talvez registrar uma desconexão no log de acesso, mas caso contrário, não tenho certeza do que fazer.

Acabei de ter o mesmo erro que travou nosso servidor da web de monitoramento:

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

Tive o mesmo com o pod executando docker image dpage / pgadmin4: 4.2

OSError: [Errno 107] Soquete não conectado
[2019-06-14 12:20:32 +0000] [77] [ERROR] Solicitação de processamento de erro de soquete.
Traceback (última chamada mais recente):
Arquivo "/usr/local/lib/python3.6/site-packages/gunicorn/workers/gthread.py", linha 274, no identificador
req = six.next (conn.parser)
Arquivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", linha 41, em __next__
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Arquivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", linha 181, em __init__
super (Solicitar, próprio) .__ init __ (cfg, unreader)
Arquivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", linha 54, em __init__
não utilizado = self.parse (self.unreader)
Arquivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", linha 230, em análise
self.headers = self.parse_headers (dados [: idx])
Arquivo "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", linha 74, em parse_headers
remote_addr = self.unreader.sock.getpeername ()

É muito parecido com: https://github.com/benoitc/gunicorn/issues/2070

Estou recebendo este erro ocasionalmente no Google Cloud Run hospedado. Abaixo está uma versão simplificada de nossa definição de contêiner:

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

O Stackdriver mostra o seguinte rastreamento de pilha:

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

Mesmo problema que o OP aqui. Usando o 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"

Estou tendo exatamente o mesmo problema 😕

Exatamente o mesmo problema que GAEfan. Executando um aplicativo Flask com Python 3.7 no ambiente padrão do App Engine.

Mesmo problema aqui

Estou tendo o mesmo problema ao executar o aplicativo Django com Python 3.7 no Google App Engine.

Traceback (última chamada mais recente): Arquivo "/env/lib/python3.7/site-packages/gunicorn/workers/sync.py", linha 134, no identificador req = six.next (analisador) Arquivo "/ env / lib / python3.7 / site-packages / gunicorn / http / parser.py ", linha 41, em __next__ self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count) Arquivo" / env / lib /python3.7/site-packages/gunicorn/http/message.py ", linha 181, em __init__ super (Request, self) .__ init __ (cfg, unreader) File" /env/lib/python3.7/site-packages /gunicorn/http/message.py ", linha 54, in __init__ unused = self.parse (self.unreader) File" /env/lib/python3.7/site-packages/gunicorn/http/message.py ", linha 230, em parse self.headers = self.parse_headers (data [: idx]) File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", linha 74, em parse_headers remote_addr = self .unreader.sock.getpeername () OSError: [Errno 107] O endpoint de transporte não está conectado

Mesmo problema ao executar GAE python 3.7 gunicorn e fastapi / uvicorn.

Mesmo problema do Google Cloud Run

de que tipo de pedido estamos falando?

mesmo problema no google app engine. Solicitação POST. acontece de forma inconsistente. App Flask. @benoitc por favor me diga quais informações seriam úteis e eu posso postar.

Mesmo problema também, Google App Engine, solicitação POST também, aplicativo Flask. Parece ter começado quando mudei para um código de ponto de entrada personalizado, em vez de deixar o padrão. O ponto de entrada personalizado é o seguinte (no Google App Engine, você o define dentro de um arquivo app.yaml):

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

O ponto de entrada padrão não está definindo nada (embora não saiba o que é usado como ponto de entrada padrão).

Não tenho certeza se começou por causa disso, mas percebi isso quando fiz essa alteração (entre outras alterações).

Não, sem proxies, sem nginx

Eu estava usando gunicorn sem nginx . Eu estava tendo o mesmo problema. Minha configuração está sendo executada em 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

a questão permanece

Mesmo problema também, Google App Engine, solicitação POST também, aplicativo Flask. Parece ter começado quando mudei para um código de ponto de entrada personalizado, em vez de deixar o padrão. O ponto de entrada personalizado é o seguinte (no Google App Engine, você o define dentro de um arquivo app.yaml):

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

O ponto de entrada padrão não está definindo nada (embora não saiba o que é usado como ponto de entrada padrão).

Não tenho certeza se começou por causa disso, mas percebi isso quando fiz essa alteração (entre outras alterações).

o que você quer dizer com ponto de entrada? você pode postar um log de depuração e a forma como a solicitação é feita? (http bruto ajudaria)

a questão permanece

Mesmo problema também, Google App Engine, solicitação POST também, aplicativo Flask. Parece ter começado quando mudei para um código de ponto de entrada personalizado, em vez de deixar o padrão. O ponto de entrada personalizado é o seguinte (no Google App Engine, você o define dentro de um arquivo app.yaml):
gunicorn -b :$PORT --timeout 1200 server.main:app
O ponto de entrada padrão não está definindo nada (embora não saiba o que é usado como ponto de entrada padrão).
Não tenho certeza se começou por causa disso, mas percebi isso quando fiz essa alteração (entre outras alterações).

o que você quer dizer com ponto de entrada? você pode postar um log de depuração e a forma como a solicitação é feita? (http bruto ajudaria)

Acho que ele está se referindo ao fato de que você está especificando explicitamente o caminho app que o _gunicorn_ deve importar-localizar e executar, como server.main:app em seu exemplo.

LE: Talvez o exemplo atualizado aqui ajude: https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/standard_python37/hello_world (então basicamente você tem que deixar o serviço lidar com como o servidor deve ser iniciado)

Em primeiro lugar, @benoitc. OBRIGADO. Seu trabalho é incrível.

Também estou tendo esse mesmo problema no Google Cloud Run com gunicorn. Estou postando o que tenho, embora provavelmente não seja o único, lendo atentamente o acima. Estou executando um aplicativo Flask com Gunicorn como servidor (e sem proxy) em um contêiner do Docker.

O traceback (do 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

E o resultado analisado do Google acima:

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)

Se houver mais alguma coisa que eu possa fornecer ou fazer para ajudar aqui, entre em contato.

Um PR seria bem-vindo para lidar com ENOTCONN graciosamente para todos os trabalhadores. Por favor, poste aqui se você começar a trabalhar nisso e eu ficaria feliz em revisar um PR. Tenho certeza de que alguns neste tópico ficarão felizes em ajudar a testar um branch.

Mesmo problema, Google App Engine, gunicorn servindo um aplicativo Django, uma pequena porcentagem de solicitações morrem assim:

entrypoint: gunicorn -b :$PORT wsgi_api:application

Um PR seria bem-vindo para lidar com ENOTCONN graciosamente para todos os trabalhadores. Por favor, poste aqui se você começar a trabalhar nisso e eu ficaria feliz em revisar um PR. Tenho certeza de que alguns neste tópico ficarão felizes em ajudar a testar um branch.

Eu sou um dos que estão neste tópico e fico feliz em ajudar no teste, então, envie um ping se eu puder ajudar.

Um PR seria bem-vindo para lidar com ENOTCONN graciosamente para todos os trabalhadores. Por favor, poste aqui se você começar a trabalhar nisso e eu ficaria feliz em revisar um PR. Tenho certeza de que alguns neste tópico ficarão felizes em ajudar a testar um branch.

Eu sou um dos que estão neste tópico e fico feliz em ajudar no teste, então, envie um ping se eu puder ajudar.

Fico feliz em ajudar a testar o PR. Se precisar de alguma ajuda, por favor me ping.

Fico feliz em ajudar a testar o PR. Se precisar de alguma ajuda, por favor me ping.

Um PR seria bem-vindo para lidar com ENOTCONN graciosamente para todos os trabalhadores. Por favor, poste aqui se você começar a trabalhar nisso e eu ficaria feliz em revisar um PR. Tenho certeza de que alguns neste tópico ficarão felizes em ajudar a testar um branch.

A causa raiz desse problema com a versão mais recente de gunicorn==19.9.0 . Fui transferido para usar a versão mais antiga de gunicorn==19.7.1 . Consegui correr sem problemas. Por favor, tente com a versão mais antiga.

em vez disso, tente o último mestre. 20,0 finalmente chegará hoje eu fui rastreado.

Qual é a aparência do seu endpoint de verificação de integridade? Como você responde a isso, você está fechando a conexão? você define o comprimento do cabeçalho e co? Não sei por que uma verificação de saúde é feita pelo correio. soa estranho...

@ cmin764 o fflask define algum cabeçalho padrão? Vou tentar, mas seria interessante atender a aparência da resposta

@benoitc Quando eu estava usando a verificação de integridade do endpoint gunicorn==19.9.0 estava muito ruim. As conexões de banco de dados estão aguardando por mais tempo. Todo o carregamento do aplicativo é interrompido.

O ponto de extremidade gunicorn==19.7.1 mais antigo está quebrando. A verificação de integridade do ponto de extremidade parece boa. Eu não estava fechando nenhuma conexão e não defini o comprimento dos cabeçalhos.

Também testarei a última versão 20.0.

Não, sem proxies, sem nginx

Eu estava usando gunicorn sem nginx . Eu estava tendo o mesmo problema. Minha configuração está sendo executada em 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

com versão anterior gunicorn = 19.7.1 I was not able to run with the gevent`. Eu mudei meu comando gunicorn

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

Estou analisando as mudanças desde esta versão para ver se há algum motivo para isso. Obrigado pelo feedback!

O uso de 19.7.1 (downgrade do mais recente) funcionou no ambiente do google app engine com filas push alimentando os workers e os workers conversando entre si por http.

O uso de 19.7.1 (downgrade do mais recente) funcionou no ambiente do google app engine com filas push alimentando os workers e os workers conversando entre si por http.

Este é meu caso de uso. Vou dar uma chance a isso.

você tentou a versão mais recente?

Última tentativa 20.0.0 em Openshift (openshift v3.11.135, kubernetes v1.11.0) - ocorre o mesmo erro. O que observei erro é gerado em carga mais alta (testes de integração executando 20 trabalhadores paralelos). O aumento do número de pods reduz a ocorrência de erros, deixando os resultados de um único pod com erro garantido. É a configuração de 3 workers de sincronização. 19.7.1 apenas não mostra nenhum erro nos logs do pod , mas o consumidor externo experimenta o mesmo EOF inesperado na conexão como na versão mais recente. Portanto, a versão degradante não ajuda.

12/11/2019 16: 08: 56.982 ERRO gunicorn.error glogging 277 glogging.py Solicitação de processamento de erro de soquete.
Traceback (última chamada mais recente):
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", linha
134, em punho
req = six.next (analisador)
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", linha 41, em __next__
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", linha 181, em __init__
super (Solicitar, próprio) .__ init __ (cfg, unreader)
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", linha 54, em __init__
não utilizado = self.parse (self.unreader)
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", linha 230, na análise
self.headers = self.parse_headers (dados [: idx])
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", linha 74, em parse_headers
remote_addr = self.unreader.sock.getpeername ()
OSError: [Errno 107] O endpoint de transporte não está conectado

Última tentativa 20.0.0 em Openshift (openshift v3.11.135, kubernetes v1.11.0) - ocorre o mesmo erro. O que observei erro é gerado em carga mais alta (testes de integração executando 20 trabalhadores paralelos). O aumento do número de pods reduz a ocorrência de erros, deixando os resultados de um único pod com erro garantido. É a configuração de 3 workers de sincronização. 19.7.1 apenas não mostra nenhum erro nos logs do pod , mas o consumidor externo experimenta o mesmo EOF inesperado na conexão como na versão mais recente. Portanto, a versão degradante não ajuda.

12/11/2019 16: 08: 56.982 ERRO gunicorn.error glogging 277 glogging.py Solicitação de processamento de erro de soquete.
Traceback (última chamada mais recente):
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", linha
134, em punho
req = six.next (analisador)
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", linha 41, no próximo
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", linha 181, no init
super (Solicitar, próprio). init (cfg, unreader)
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", linha 54, no init
não utilizado = self.parse (self.unreader)
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", linha 230, na análise
self.headers = self.parse_headers (dados [: idx])
Arquivo "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", linha 74, em parse_headers
remote_addr = self.unreader.sock.getpeername ()
OSError: [Errno 107] O endpoint de transporte não está conectado

Você pode tentar aumentar o tempo limite do

Você pode tentar aumentar o tempo limite do

Seguindo esta pista, encontramos o problema : A configuração da sondagem de prontidão Openshift era muito otimista (o aplicativo demorou muito para algumas solicitações) e, em caso de falha, o balanceador de carga externo (AVI) detectou este evento e expulsou o pod do pool de balanceamento de carga.

Recentemente, tive esse problema com gunicorn = 19.9.0. A reinicialização resolveu o problema. Estou implantado no Google Kubernetes Engine. O aplicativo é um aplicativo Flask -
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 = '-'

Erro:
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

A solução atual é fazer o downgrade para 19.7.1 ?

Alguém pode compartilhar um repositório com instruções de implantação que eu possa usar para reproduzir o problema? Fico feliz em investigar isso, mas quero ter certeza de que sei exatamente como configurá-lo.

Olá, @tilgovi Fastapi usa gunicorn na produção.
Este repositório possui uma versão mínima e apresentou o mesmo erro. Você pode tentar, eu tenho esse erro no App Engine, não sei se ele se replica com outros ambientes. Esse repositório poderia ajudar a reproduzir o problema?

O mesmo problema aqui:
gunicorn 19.9.0 + GKE também ocorria quando estávamos lidando com alta carga.

cmin

Não tenho certeza, mas tudo parece voltar ao normal agora.

Este é meu 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

E execução de produção do 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

Então, talvez fosse algo temporário no GAE.

Eu tenho o mesmo problema. Gunicorn com gevent, apenas um LB de HTTP do Google na frente. (sem Nginx ou outro proxy reverso). As coisas funcionam bem por semanas, mas de vez em quando eu consigo:

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.

Fato que várias pessoas relataram que isso “acontece sob carga alta” ou que, no meu caso, isso acontece “algumas vezes por mês” parece que é algum tipo de condição de corrida.

@JordanP fo você tem algum erro do lado do google? Como é enviar o ping do Google LB? O tempo limite no Google LB side?

Está sendo executado no Kubernetes, a verificação de integridade é HTTP, muito conservadora (tempo limite de 5 segundos, 10 falhas consecutivas antes de marcar os contêineres como mortos).

No lado do Google, o HTTP LB na frente do Gunicorn retornou mais de 40k 502 erros (em alguns minutos) com a seguinte razão: "backend_timeout":

Eu tenho 4 réplicas (4 contêineres), todos eles travaram ao mesmo tempo naquela noite. Portanto, é uma suposição absurda, mas talvez o Google tenha que reiniciar seu balanceador de carga para implantar uma nova versão, uma correção, seja o que for, é tudo software, afinal, então o cliente (como visto por Gunicorm) pode ter se desconectado de uma forma hostil / não maneira esperada. De qualquer forma, Gunicorn deve ser resiliente a qualquer situação de cliente que aconteça.

Ignorar ENOTCONN parece normal, foi discutido fazer isso diretamente em alguns módulos do stdlib do Python, para algumas operações: https://bugs.python.org/issue30319#msg297643

Mesmo erro.

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

Dois aplicativos de flask (api e interface) em contêineres docker separados, cada um executando o gunicorn. O erro ocorre no Chrome / Chromium (não no firefox), quando posto na API por meio de um formulário no aplicativo de interface. Ele pode ser conectado às conexões TCP preemptivas do Chrome. Como o nginx deve ser capaz de lidar com isso, coloquei-o na frente dos contêineres. Não muda nada.

@uree qual trabalhador? Como você inicia o gunicorn?

CMD ["gunicorn", " app: app ", "-b", "0.0.0.0:8001", "-t 90"]
Eu também tentei
CMD ["gunicorn", " app: app ", "-b", "0.0.0.0:8001", "-t 90", "--preload"]

Estou tendo o mesmo problema ao executar django com gunicorn com docker-compose no Digital Ocean.
Gunicorn versão 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 erro ocorre a 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

Mesmo erro.

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

Dois aplicativos de flask (api e interface) em contêineres docker separados, cada um executando o gunicorn. O erro ocorre no Chrome / Chromium (não no firefox), quando posto na API por meio de um formulário no aplicativo de interface. Ele pode ser conectado às conexões TCP preemptivas do Chrome. Como o nginx deve ser capaz de lidar com isso, coloquei-o na frente dos contêineres. Não muda nada.

Atualizar No meu caso, o problema estava em outro lugar. Foi causado por um evento onclick jquery em um botão de envio. Tive que postar de forma assíncrona com ajax para resolver o problema.

Existem atualizações sobre este erro?

Existem atualizações sobre este erro?

bem, você pode descrever o contexto em que está acontecendo? Além disso, com o uso desse kubernetes, você pode descrever como sua verificação de integridade está configurada para que possamos reproduzi-la?

O que o faz pensar que está relacionado ao Kubernetes? Nenhum cliente com comportamento incorreto, a conexão semifechada deve travar completamente um trabalhador Gunicorn, esteja ele em execução em Kubernetes, Mesos, docker, baremetal: o Gunicorn deve ser resiliente.

Não encontrei um reprodutor confiável / fácil, mas se eu encontrar, acho que posso travar todos os servidores da web gunicorn diretamente expostos à Internet.

bem, eu nunca tive esse acidente quando o gunicorn está atrás do nginx e alguns emitidos
relatado lá parece relacionado a kubernetes.

Em qual trabalhador isso está acontecendo? O gunicorn é usado por trás de um proxy? Que
1?

Na terça-feira, 10 de março de 2020, às 11h52, Jordan Pittier [email protected] escreveu:

O que o faz pensar que está relacionado ao Kubernetes? Nenhum cliente malcomportado, meio
conexão fechada deve sempre travar completamente um trabalhador Gunicorn, seja
está sendo executado em Kubernetes, Mesos, docker, baremetal: Gunicorn deve ser
resiliente.

Não encontrei um reprodutor confiável / fácil, mas se eu encontrar, acho que posso ser
capaz de travar todos os servidores da web gunicorn diretamente expostos ao
Internet.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/benoitc/gunicorn/issues/1913?email_source=notifications&email_token=AAADRITYFZI4GINCSG752OTRGYLXDA5CNFSM4GBYQQA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOK5V2I#issuecomment-597023465 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAADRIRSO4T7WQTS6GMHLO3RGYLXDANCNFSM4GBYQQAQ
.

>

Enviado do meu celular

Mesmo erro com um serviço aws ecs por trás de um balanceador de carga aws.
Aconteceu uma vez ao mesmo tempo em todas as réplicas (contêineres / tarefas)
Gunicorn como pacote pip. Sem Nginx, sem proxy.
Python 3.7.6
Versão Gunicorn: 20.0.4
Corra como:
gunicorn --bind 0.0.0.0:8000 --workers 1 --threads 5 --max-requests 100 --timeout 300 application.wsgi
Registro:
[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

Existem atualizações sobre este erro?

bem, você pode descrever o contexto em que está acontecendo? Além disso, com o uso desse kubernetes, você pode descrever como sua verificação de integridade está configurada para que possamos reproduzi-la?

Não tenho nada específico. O erro ocorre do nada, nenhuma ação perceptível acontece que causa esse erro.
No aplicativo django, diferente dos endpoints regulares da API REST, há um agendador de tarefas django. Todo o resto você pode ver no docker-compose.yml.

Posso fornecer mais alguns dados. Estou vendo isso ocasionalmente com o gunicorn 19.9.0 em execução atrás do haproxy como um proxy reverso (apenas usando HTTP, não usando o 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

O servidor estava lidando com cerca de 30 solicitações / segundo na época. Como você pode ver, a primeira linha de log foi mutilada, provavelmente devido à saída em buffer e vários trabalhadores.

Gunicorn está sendo executado com systemd: ExecStart=/var/venvs/software-venv/bin/gunicorn -b 0.0.0.0:6000 -w 4 app:app e LimitNOFILE=49152 .

Enviei uma solicitação de pull com uma correção que estou executando em produção há alguns dias. O bug é causado por uma condição de corrida, onde o soquete pode ser fechado (por qualquer cliente, sistema operacional, etc.) antes de getpeername() ser chamado, então ele levanta uma exceção corretamente. No entanto, o gunicorn não está pegando essa exceção, então está borbulhando e travando o servidor. Minha correção é apenas capturar a exceção e levantá-la como uma exceção NoMoreData, que já é tratada por outro código mais acima na pilha. Isso evita que uma desconexão mal programada cause falha no servidor.

Também existe esse PR https://github.com/benoitc/gunicorn/pull/2277

Estou usando o Kubernetes (1.16.8-gke.15) e o Gunicorn mais recente (20.0.4) e o Python 3.7. Se eu fizer uma solicitação POST e aumentar um atraso de tempo começando com 1 segundo para cada iteração, ele para de funcionar quando o atraso é de 360 ​​segundos. O trabalho dentro do Gunicorn está concluído e alguns minutos depois ele retorna este erro:

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

Quando a conexão cai entre o Kubernetes e o Gunicorn, o endpoint do Kubernetes e o cliente ainda estão conectados. As verificações de integridade parecem boas, mas é possível que estejam configuradas incorretamente de alguma forma. Não encontrei nenhum registro no lado do Kubernetes para identificar o problema.

Tive o mesmo resultado para Gunicorn (19.7.1).

Eu adicionei a sinalização de tempo limite para Gunicorn e estou usando o balanceador de carga GKE padrão com adicionar anotações para lidar com qualquer tempo limite. Comando Gunicorn:

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

Quando executo o Gunicorn localmente sem nada na frente, ele funciona bem. Isso pode ser mais um problema do Kubernetes , no entanto, a resposta está perdida.

Alguém teve alguma sorte com este problema? Ou uma boa maneira de depurar isso?

Docker versão 19.03.8, compilação afacb8b7f0

Python 3.8.2 (padrão, 26 de fevereiro de 2020, 15:09:34)
[GCC 8.3.0] no 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

No meu caso, descobri que qualquer solicitação HEAD emite isso.

Estou usando django atrás de gunicorn e suspeito que o aplicativo deseja escrever um corpo de resposta (não deveria), mas não confirmei que seja o caso ainda.

mesmo comportamento

Eu acho que isso pode ser corrigido pelo # 2277

No meu caso, o módulo wait_for do Ansible é a causa.

Eu uso o Ansible para implantar um servidor gunicorn + flask (especificamente Python 3.6.12, gunicorn 19.9.0, Flask 1.4.1).

Depois de iniciar o serviço, eu uso o módulo wait_for para ter certeza de que o serviço está instalado e funcionando.
Este módulo provavelmente interrompe a conexão imediatamente após validar que o serviço está ativo (sem esperar a resposta do gunicorn) e, portanto, o gunicorn gera esse erro.

Acho que outros sistemas de monitoramento fazem o mesmo.

Recebi o mesmo erro .. hmm
Atualmente, temos um tráfego enorme .. 100-1000 TPS, e algumas solicitações falharam aleatoriamente

Python 3.8
Frasco
Gunicorn

Com as propriedades do docker abaixo ..

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

Qualquer solução?

Há alguma atualização sobre isso?
Parece que há vários PRs para consertar. Temos um cronograma para liberá-los?

Oi @tilgovi
Temos um cronograma para lançar esta nova versão? parece que o pacote Gunicorn não atualiza por um longo tempo ...

Farei um lançamento provavelmente hoje. Vou verificar novamente este problema enotconn porque não estou satisfeito com a solução comprometida. @tilgovi tem outra correção que pode ser testada.

?

você testou o outro patch para ajudar?

obrigado, gostaria de saber se existe alguma informação de atualização sobre o pacote pip?

@yehjames é o mestre trabalhando para você? Um lançamento está planejado agora para hoje. Mas qualquer feedback sobre como o master funciona em diferentes plataformas é bem-vindo.

@benoitc Alguma atualização sobre isso? Usar 20.0.4 na produção e implementar a mudança sugerida por @asantoni (como um patch monkey) para evitar travamentos freqüentes. Mas a verificação de código estático do Veracode não gosta do patch, então tente consertá-lo agora. Obrigado!

Vamos trabalhar para liberar o mais rápido possível. Não podemos prometer um dia, mas estamos trabalhando para descobrir o que resta para este lançamento e para melhorar o gerenciamento de lançamentos para o futuro.

Use o recurso "Watch" do GitHub para o repositório e observe os lançamentos se quiser ser notificado.

Oi. Estou tendo o mesmo problema com o HAProxy + Gunicorn + Django.

Meu back-end HAProxy perde quase todos os seus servidores devido a verificações não respondidas e os logs do Gunicorn são afetados por:

[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

Estou trabalhando com gunicorn == 20.0.4, Django == 3.1.5, HA-Proxy versão 2.2.11-1ppa1 ~ bionic

Alguma pista de como proceder?

Este está no modo TCP, sem SSL, no Locust Stress Testing.

Alguém, por favor, compartilhe a solução sobre este problema

@krishnamanchikalapudi @ricarhincapie atualize para a versão mais recente do Gunicorn :)