Gunicorn: Розетки

Есть ли в вашем модуле что-нибудь интересное перед Gunicorn, например, обратный прокси, nginx?

Нет, ни прокси, ни nginx

У меня точно такая же проблема: confused:

В восходящем направлении у нас есть HAProxy, и в его формате журнала HTTP состояние сеанса при отключении (см. Http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#8.5) он регистрирует эти ошибки как CH-- значение:

• C: сеанс TCP был неожиданно прерван клиентом.
• H: прокси-сервер ожидал полного, действительного ответа HEADERS от сервера (только HTTP).

Итак, если я правильно понимаю, клиент закрыл соединение, пока Gunicorn все еще отправлял ответ.

Есть какие-нибудь подсказки, что заставляет клиента прервать работу? Долго ли он ждал, пока Gunicorn отправит полные заголовки ответа?

@javabrett , похоже, что это не так, по крайней мере, в нескольких сообщениях журнала, которые я просмотрел, это в основном изображения или другие ресурсы, поэтому это не должно занять много времени.

Клиент мог закрыть браузер или выполнить какое-либо другое действие, которое могло бы резко закрыть соединение? : мышление:

@gforcada вы используете протокол прокси с haproxy?

@benoitc я не знаю

кто-нибудь добьется чего-нибудь с этим? Мне нечего добавить, кроме той же самой ошибки.

Моя конфигурация состоит из балансировщика нагрузки, который используется для завершения SSL и перенаправления запросов в приложение django, работающее в контейнере докеров. Я не уверен, с чем реализован LB - это продукт Digital Ocean.

Я почти уверен, что это связано с балансировщиком нагрузки, потому что у меня такое же приложение работает в другом контейнере, который не находится за LB, и у него никогда не было этой проблемы.

Есть идеи о первопричине и о том, как предотвратить?

Интересно, есть ли здесь какое-нибудь действие. Если это обычное отключение клиента, мы могли бы отключить эту ошибку и, возможно, зарегистрировать отключение в журнале доступа, но в противном случае я не уверен, что делать.

У меня была такая же ошибка, которая привела к сбою нашего веб-сервера мониторинга:

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

У меня было то же самое с подом, на котором запущено изображение докера dpage / pgadmin4: 4.2

OSError: [Errno 107] Сокет не подключен
[2019-06-14 12:20:32 +0000] [77] [ERROR] Запрос обработки ошибки сокета.
Отслеживание (последний вызов последний):
Файл "/usr/local/lib/python3.6/site-packages/gunicorn/workers/gthread.py", строка 274, в дескрипторе
req = six.next (conn.parser)
Файл "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", строка 41, в __next__
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Файл "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", строка 181, в __init__
super (Запрос, сам) .__ init __ (cfg, unreader)
Файл "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", строка 54, в __init__
unused = self.parse (self.unreader)
Файл "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", строка 230, в синтаксическом анализе
self.headers = self.parse_headers (данные [: idx])
Файл "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", строка 74, в parse_headers
remote_addr = self.unreader.sock.getpeername ()

Очень похоже на: https://github.com/benoitc/gunicorn/issues/2070

Я иногда получаю эту ошибку в размещенном на сервере Google Cloud Run. Ниже представлена ​​упрощенная версия определения нашего контейнера:

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 показывает следующую трассировку стека:

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

Та же проблема, что и у OP. Использование 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"

У меня точно такая же проблема 😕

Та же проблема, что и у GAEfan. Запуск приложения Flask с Python 3.7 в стандартной среде App Engine.

Такая же проблема здесь

У меня такая же проблема с запуском приложения Django с Python 3.7 в Google App Engine.

Отслеживание (последний вызов последним): файл "/env/lib/python3.7/site-packages/gunicorn/workers/sync.py", строка 134, в дескрипторе req = six.next (parser) File "/ env / lib / python3.7 / site-packages / gunicorn / http / parser.py ", строка 41, в файле __next__ self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)" / env / lib /python3.7/site-packages/gunicorn/http/message.py ", строка 181, в __init__ super (Request, self) .__ init __ (cfg, unreader) File" /env/lib/python3.7/site-packages /gunicorn/http/message.py ", строка 54, в файле __init__ unused = self.parse (self.unreader)" /env/lib/python3.7/site-packages/gunicorn/http/message.py ", строка 230, в синтаксическом анализе self.headers = self.parse_headers (data [: idx]) Файл "/env/lib/python3.7/site-packages/gunicorn/http/message.py", строка 74, в parse_headers remote_addr = self .unreader.sock.getpeername () Ошибка OSError: [Errno 107] Конечная точка транспорта не подключена

Такая же проблема с GAE python 3.7 gunicorn и fastapi / uvicorn.

Та же проблема, Google Cloud Run

о каком запросе идет речь?

такая же проблема в движке приложений Google. POST запрос. бывает непоследовательно. Приложение Flask. @benoitc, пожалуйста, дайте мне знать, какая информация будет полезна, и я могу опубликовать ее.

Та же проблема, Google App Engine, запрос POST, приложение Flask. Похоже, это началось, когда я перешел на собственный код точки входа вместо того, чтобы оставить код по умолчанию. Пользовательская точка входа следующая (в Google App Engine вы устанавливаете ее внутри файла app.yaml):

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

Точка входа по умолчанию ничего не устанавливает (хотя не знаю, что используется в качестве точки входа по умолчанию).

Не уверен, что это началось из-за этого, но я заметил это, когда внес это изменение (среди других изменений).

Нет, ни прокси, ни nginx

Я использовал gunicorn без nginx . У меня была такая же проблема. Моя установка работает на 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

вопрос стенд

Та же проблема, Google App Engine, запрос POST, приложение Flask. Похоже, это началось, когда я перешел на собственный код точки входа вместо того, чтобы оставить код по умолчанию. Пользовательская точка входа следующая (в Google App Engine вы устанавливаете ее внутри файла app.yaml):

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

Точка входа по умолчанию ничего не устанавливает (хотя не знаю, что используется в качестве точки входа по умолчанию).

Не уверен, что это началось из-за этого, но я заметил это, когда внес это изменение (среди других изменений).

что вы подразумеваете под точкой входа? Можете ли вы опубликовать журнал отладки и способ выполнения запроса? (необработанный http поможет)

вопрос стенд

Та же проблема, Google App Engine, запрос POST, приложение Flask. Похоже, это началось, когда я перешел на собственный код точки входа вместо того, чтобы оставить код по умолчанию. Пользовательская точка входа следующая (в Google App Engine вы устанавливаете ее внутри файла app.yaml):
gunicorn -b :$PORT --timeout 1200 server.main:app
Точка входа по умолчанию ничего не устанавливает (хотя не знаю, что используется в качестве точки входа по умолчанию).
Не уверен, что это началось из-за этого, но я заметил это, когда внес это изменение (среди других изменений).

что вы подразумеваете под точкой входа? Можете ли вы опубликовать журнал отладки и способ выполнения запроса? (необработанный http поможет)

Я думаю, он имеет в виду тот факт, что вы явно указываете путь app _gunicorn_ должен импортировать-найти и запустить, как server.main:app в его примере.

LE: Может быть, обновленный пример здесь поможет: https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/standard_python37/hello_world (так что в основном вы должны позволить службе управлять тем, как должен быть сервер начал)

Во-первых, @benoitc СПАСИБО. Твоя работа потрясающая.

У меня такая же проблема с Google Cloud Run w / gunicorn. Я публикую то, что у меня есть, хотя это, вероятно, не уникальное, просматривая выше. Я запускаю приложение Flask с Gunicorn в качестве сервера (без прокси) в контейнере Docker.

Отслеживание (с консоли 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

И проанализированный Google вывод вышеупомянутого:

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)

Если я могу еще чем-то помочь или чем-то помочь, пожалуйста, дайте мне знать.

Будет приветствоваться PR, который изящно обработает ENOTCONN для всех рабочих. Пожалуйста, напишите здесь, если вы начнете работать над этим, и я буду рад просмотреть PR. Я уверен, что некоторые участники этой темы будут рады помочь в тестировании ветки.

Та же проблема, Google App Engine, gunicorn, обслуживающий приложение Django, небольшой процент запросов умирает следующим образом:

entrypoint: gunicorn -b :$PORT wsgi_api:application

Будет приветствоваться PR, который изящно обработает ENOTCONN для всех рабочих. Пожалуйста, напишите здесь, если вы начнете работать над этим, и я буду рад просмотреть PR. Я уверен, что некоторые участники этой темы будут рады помочь в тестировании ветки.

Я один из тех, кто находится в этой теме, и рад помочь в тестировании, поэтому, пожалуйста, свяжитесь со мной, если я могу помочь.

Будет приветствоваться PR, который изящно обработает ENOTCONN для всех рабочих. Пожалуйста, напишите здесь, если вы начнете работать над этим, и я буду рад просмотреть PR. Я уверен, что некоторые участники этой темы будут рады помочь в тестировании ветки.

Я один из тех, кто находится в этой теме, и рад помочь в тестировании, поэтому, пожалуйста, свяжитесь со мной, если я могу помочь.

Рад помочь проверить PR. Если нужна помощь, пожалуйста, свяжитесь со мной.

Рад помочь проверить PR. Если нужна помощь, пожалуйста, свяжитесь со мной.

Будет приветствоваться PR, который изящно обработает ENOTCONN для всех рабочих. Пожалуйста, напишите здесь, если вы начнете работать над этим, и я буду рад просмотреть PR. Я уверен, что некоторые участники этой темы будут рады помочь в тестировании ветки.

Основная причина этой проблемы в последней версии gunicorn==19.9.0 . Меня перевели на старую версию gunicorn==19.7.1 . Я смог бежать без каких-либо проблем. Пожалуйста, попробуйте более старую версию.

лучше попробуй последний мастер. Сегодня, наконец, выйдет 20.0, меня отвлекли.

Как выглядит ваша конечная точка проверки работоспособности? Как вы на это реагируете, закрываете ли вы соединение? вы устанавливаете длину заголовка и co? Я не уверен, почему проверка работоспособности проводится по почте. звучит странно...

@ cmin764 устанавливает ли fflask какой-либо заголовок по умолчанию? Я постараюсь, но было бы интересно посмотреть, как выглядит ответ

@benoitc Когда я использовал gunicorn==19.9.0 проверка работоспособности конечной точки

старые gunicorn==19.7.1 Endpoint ломаются. Проверка работоспособности конечных точек выглядит хорошо. Я не закрывал никаких соединений и не устанавливал длину заголовков.

Так же протестирую последнюю версию 20.0.

Нет, ни прокси, ни nginx

Я использовал gunicorn без nginx . У меня была такая же проблема. Моя установка работает на 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

с более старой версией gunicorn = 19.7.1 I was not able to run with the gevent`. Я изменил свою команду пулеметчика

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

Я смотрю на изменения, произошедшие с этой версии, чтобы узнать, есть ли для этого причина. Спасибо за ответ!

Использование версии 19.7.1 (понижение с последней версии) работало в среде движка приложений Google с очередями push, которые питали рабочих, а рабочие общались друг с другом по протоколу http.

Использование версии 19.7.1 (понижение с последней версии) работало в среде движка приложений Google с очередями push, которые питали рабочих, а рабочие общались друг с другом по протоколу http.

Это мой вариант использования. Я попробую.

вы пробовали последнюю версию?

Пробовал последнюю версию 20.0.0 на Openshift (openshift v3.11.135, kubernetes v1.11.0) - возникает та же ошибка. То, что я заметил, ошибка срабатывает при более высокой нагрузке (интеграционные тесты с 20 параллельными рабочими). Увеличение количества модулей снижает вероятность ошибки, а оставление одного модуля приводит к гарантированной ошибке. Это конфигурация 3 рабочих процессов синхронизации. 19.7.1 просто не показывает ошибок в журналах модуля , но внешний потребитель испытывает тот же неожиданный EOF при подключении, как и в последней версии. Так что унизительная версия не помогает.

2019-11-12 16: 08: 56,982 ERROR gunicorn.error glogging 277 glogging.py Запрос обработки ошибки сокета.
Отслеживание (последний вызов последний):
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", строка
134, в ручке
req = six.next (парсер)
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", строка 41, в __next__
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", строка 181, в __init__
super (Запрос, сам) .__ init __ (cfg, unreader)
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", строка 54, в __init__
unused = self.parse (self.unreader)
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", строка 230, в синтаксическом анализе
self.headers = self.parse_headers (данные [: idx])
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", строка 74, в parse_headers
remote_addr = self.unreader.sock.getpeername ()
OSError: [Errno 107] Конечная точка транспорта не подключена

Пробовал последнюю версию 20.0.0 на Openshift (openshift v3.11.135, kubernetes v1.11.0) - возникает та же ошибка. То, что я заметил, ошибка срабатывает при более высокой нагрузке (интеграционные тесты с 20 параллельными рабочими). Увеличение количества модулей снижает вероятность ошибки, а оставление одного модуля приводит к гарантированной ошибке. Это конфигурация 3 рабочих процессов синхронизации. 19.7.1 просто не показывает ошибок в журналах модуля , но внешний потребитель испытывает тот же неожиданный EOF при подключении, как и в последней версии. Так что унизительная версия не помогает.

2019-11-12 16: 08: 56,982 ERROR gunicorn.error glogging 277 glogging.py Запрос обработки ошибки сокета.
Отслеживание (последний вызов последний):
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", строка
134, в ручке
req = six.next (парсер)
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", строка 41, далее
self.mesg = self.mesg_class (self.cfg, self.unreader, self.req_count)
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", строка 181, в init
super (Запрос, сам). init (cfg, unreader)
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", строка 54, в init
unused = self.parse (self.unreader)
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", строка 230, в синтаксическом анализе
self.headers = self.parse_headers (данные [: idx])
Файл "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", строка 74, в parse_headers
remote_addr = self.unreader.sock.getpeername ()
OSError: [Errno 107] Конечная точка транспорта не подключена

Можете попробовать увеличить таймаут роутера.

Можете попробовать увеличить таймаут роутера.

Следуя этому примеру, мы обнаружили проблему : настройка проверки готовности Openshift была слишком оптимистичной (приложение слишком долго обрабатывало некоторые запросы), а в случае сбоя внешний балансировщик нагрузки (AVI) обнаружил это событие и выгнал модуль из пула балансировки нагрузки.

Недавно я столкнулся с этой проблемой с gunicorn = 19.9.0. Перезапуск решил проблему. Я развернут на Google Kubernetes Engine. Приложение представляет собой приложение-флягу -
Вход:
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 = '-'

Ошибка:
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

Можно ли понизить текущее решение до 19.7.1 ?

Может ли кто-нибудь поделиться репозиторием с инструкциями по развертыванию, которые я могу использовать для воспроизведения проблемы? Я счастлив разобраться в этом, но хочу убедиться, что точно знаю, как его настроить.

Привет, @tilgovi Fastapi использует Gunicorn в производстве.
Этот репозиторий имеет минимальную версию и показывает ту же ошибку. Вы можете попробовать, у меня была эта ошибка в App Engine, я не знаю, реплицируется ли она в других средах. Этот репозиторий может помочь воспроизвести проблему?

Такая же проблема здесь:
gunicorn 19.9.0 + GKE тоже возникало, когда мы имели дело с большой нагрузкой.

cmin

Не уверен, но теперь все возвращается в норму.

Это мой 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

И производственный цикл 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

Так что, возможно, это было что-то временное в GAE.

У меня такая же проблема. Gunicorn с gevent, впереди только Google HTTP LB. (нет Nginx или другого обратного прокси). Все работает нормально неделями, но время от времени я получаю:

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.

Тот факт, что несколько человек сообщили, что он «происходит под высокой нагрузкой» или что, в моем случае, это происходит «несколько раз в месяц», похоже, что это своего рода состояние гонки.

@JordanP У вас есть ошибка на стороне Google? Как отправить пинг из Google LB? Есть ли тайм-аут на стороне Google LB?

Он работает в Kubernetes, проверка работоспособности - HTTP, очень консервативная (тайм-аут 5 секунд, 10 последовательных сбоев перед тем, как пометить контейнеры как мертвые).

На стороне Google HTTP LB перед Gunicorn вернул более 40 000 ошибок 502 (за пару минут) со следующей причиной: "backend_timeout":

У меня есть 4 реплики (4 контейнера), все они разбились одновременно в ту ночь. Итак, это дикая догадка, но, возможно, Google пришлось перезапустить свой балансировщик нагрузки, чтобы развернуть новую версию, исправление, что угодно, в конце концов, это все программное обеспечение, поэтому клиент (как видит Gunicorm), возможно, отключился из-за недружественного / недружественного ожидаемый способ. В любом случае Gunicorn должен быть устойчивым к любой ситуации с клиентом.

Игнорирование ENOTCONN выглядит нормально, это обсуждалось непосредственно в некоторых модулях Python stdlib для некоторых операций: https://bugs.python.org/issue30319#msg297643

Та же ошибка.

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

Два фляжных приложения (api и interface) в отдельных контейнерах докеров, каждое из которых запускает gunicorn. Ошибка возникает в Chrome / Chromium (не firefox), когда я отправляю сообщение в api через форму в приложении интерфейса. Это может быть связано с вытесняющими TCP-соединениями Chrome. Поскольку nginx должен уметь их обрабатывать, я поставил его перед контейнерами. Ничего не меняет.

@uree какой рабочий? Как запустить пулемет?

CMD ["пулемет", " приложение: приложение ", "-b", "0.0.0.0:8001", "-t 90"]
Я также пробовал
CMD ["gunicorn", " app: app ", "-b", "0.0.0.0:8001", "-t 90", "--preload"]

Я вижу ту же проблему при запуске django с gunicorn с docker-compose в Digital Ocean.
Gunicorn версии 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

Эта ошибка возникает каждые 4-5 минут:

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

Та же ошибка.

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

Два фляжных приложения (api и interface) в отдельных контейнерах докеров, каждое из которых запускает gunicorn. Ошибка возникает в Chrome / Chromium (не firefox), когда я отправляю сообщение в api через форму в приложении интерфейса. Это может быть связано с вытесняющими TCP-соединениями Chrome. Поскольку nginx должен уметь их обрабатывать, я поставил его перед контейнерами. Ничего не меняет.

Обновление В моем случае проблема была в другом месте. Это было вызвано событием jquery onclick на кнопке отправки. Мне пришлось отправлять сообщения асинхронно с помощью ajax, чтобы решить проблему.

Есть ли обновления по этой ошибке?

Есть ли обновления по этой ошибке?

ну вы можете описать контекст, в котором это происходит? Также, несмотря на все это, используя эти кубернеты, можете ли вы описать, как настроена ваша проверка здоровья, чтобы мы могли ее воспроизвести?

Что заставляет думать, что это связано с Kubernetes? Никакой неправильно работающий клиент, полузакрытое соединение никогда не должно полностью приводить к сбою воркера Gunicorn, независимо от того, работает ли он в Kubernetes, Mesos, docker, baremetal: Gunicorn наиболее устойчив.

Я не нашел надежного / простого воспроизводящего устройства, но если я найду, думаю, я смогу вывести из строя все веб-серверы Gunicorn, напрямую подключенные к Интернету.

ну, у меня никогда не было такого сбоя, когда Gunicorn стоит за nginx, а некоторые выдавали
сообщенный там кажется связанным с kubernetes.

На каком воркере это происходит? Используется ли Gunicorn через прокси? Который
один?

Во вторник, 10 марта 2020 г., в 11:52 Джордан Питтье пишет: [email protected]

Что заставляет думать, что это связано с Kubernetes? Нет плохого клиента, половина
закрытое соединение должно когда-либо полностью приводить к аварийному завершению работника Gunicorn, независимо от того,
он работает в Kubernetes, Mesos, Docker, baremetal: скорее всего, Gunicorn
устойчивый.

Я не нашел надежного / простого воспроизводящего устройства, но если найду, думаю,
может вывести из строя все веб-серверы Gunicorn, напрямую связанные с
Интернет.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/benoitc/gunicorn/issues/1913?email_source=notifications&email_token=AAADRITYFZI4GINCSG752OTRGYLXDA5CNFSM4GBYQQA2YY3PNVWWK3TUL52-5DFVREXW9WWWK3TUL52H4DFVREXW2HS4DFVREXWG43
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAADRIRSO4T7WQTS6GMHLO3RGYLXDANCNFSM4GBYQQAQ
.

>

Отправлено с моего мобильного

Та же ошибка с сервисом aws ecs за балансировщиком нагрузки aws.
Произошло единовременно на всех репликах (контейнерах / задачах)
Gunicorn как пакет pip. Ни Nginx, ни прокси.
Python 3.7.6
Версия Gunicorn: 20.0.4
Беги как:
gunicorn --bind 0.0.0.0:8000 --workers 1 --threads 5 --max-requests 100 --timeout 300 application.wsgi
Бревно:
[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

Есть ли обновления по этой ошибке?

ну вы можете описать контекст, в котором это происходит? Также, несмотря на все это, используя эти кубернеты, можете ли вы описать, как настроена ваша проверка здоровья, чтобы мы могли ее воспроизвести?

У меня нет ничего конкретного. Ошибка возникает из ниоткуда, никаких заметных действий, вызывающих эту ошибку, не происходит.
В приложении django, кроме обычных конечных точек REST API, есть планировщик заданий django. Все остальное вы можете увидеть в docker-compose.yml.

Могу предоставить еще несколько данных. Я иногда наблюдаю это, когда gunicorn 19.9.0 работает за haproxy в качестве обратного прокси (просто используя HTTP, а не протокол 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

В то время сервер обрабатывал около 30 запросов в секунду. Как видите, первая строка журнала была искажена, предположительно из-за буферизации вывода и нескольких рабочих процессов.

Gunicorn запускается с systemd: ExecStart=/var/venvs/software-venv/bin/gunicorn -b 0.0.0.0:6000 -w 4 app:app и LimitNOFILE=49152 .

Я отправил запрос на вытягивание с исправлением, которое я использую в производственной среде уже несколько дней. Ошибка вызвана состоянием гонки, когда сокет может быть закрыт (клиентом, ОС и т. Д.) До getpeername() , поэтому он правильно вызывает исключение. Однако Gunicorn не перехватывает это исключение, поэтому он всплывает и приводит к сбою сервера. Мое исправление состоит в том, чтобы просто перехватить исключение и вызвать его как исключение NoMoreData, которое уже обрабатывается другим кодом, находящимся дальше в стеке. Это предотвращает сбой сервера из-за несвоевременного отключения.

Там тоже есть этот пиар https://github.com/benoitc/gunicorn/pull/2277

Я использую Kubernetes (1.16.8-gke.15) и последнюю версию Gunicorn (20.0.4), а также Python 3.7. Если я сделаю запрос POST и увеличу задержку, начиная с 1 секунды для каждой итерации, он перестанет работать, когда задержка составит 360 секунд. Работа внутри Gunicorn завершена, и через несколько минут возвращается следующая ошибка:

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

Когда соединение между Kubernetes и Gunicorn разрывается, конечная точка Kubernetes и клиент все еще подключены. Проверки работоспособности выглядят неплохо, но, возможно, они каким-то образом неправильно настроены. Я не нашел никаких журналов на стороне Kubernetes для определения проблемы.

У меня был такой же результат для Gunicorn (19.7.1).

Я добавил флаг тайм-аута для Gunicorn, и я использую GKE Loadbalancer по умолчанию с BackendConfig для Kubernetes GKE . Я также пробовал использовать NGINX Ingress и добавлять аннотации для обработки любых таймаутов. Команда Gunicorn:

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

Когда я запускаю Gunicorn локально без чего-либо перед ним, он работает нормально. Это может быть больше проблема Kubernetes , однако ответ теряется.

Кому-нибудь повезло с этой проблемой? Или хороший способ отладить это?

Докер версии 19.03.8, сборка afacb8b7f0

Python 3.8.2 (по умолчанию, 26 февраля 2020 г., 15:09:34)
[GCC 8.3.0] в 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

В моем случае я обнаружил, что любой запрос HEAD выдает это.

Я использую django за gunicorn, и я подозреваю, что приложение хочет написать тело ответа (не должно), но я еще не подтвердил, что это так.

такое же поведение

Думаю, это можно исправить с помощью # 2277.

В моем случае причиной является модуль Ansible wait_for .

Я использую Ansible для развертывания сервера gunicorn + flask (в частности, Python 3.6.12, gunicorn 19.9.0, Flask 1.4.1).

После запуска службы я использую модуль wait_for, чтобы убедиться, что служба запущена и работает.
Этот модуль, вероятно, разрывает соединение сразу после того, как он проверяет, что служба запущена (не дожидаясь ответа gunicorn), и, таким образом, gunicorn вызывает эту ошибку.

Думаю, другие системы мониторинга делают то же самое.

У меня такая же ошибка .. хм
В настоящее время у нас огромный трафик. 100–1000 TPS, и некоторые запросы случайно не удались.

Python 3.8
Колба
Gunicorn

Со свойствами докера ниже ..

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

Любое решение?

Есть ли обновления по этому поводу?
Кажется, есть несколько PR, чтобы исправить это, есть ли у нас сроки их выпуска?

Привет @tilgovi
Есть ли у нас сроки выпуска этой новой версии? вроде пакет Gunicorn давно не обновляется ...

Релиз сделаю наверное сегодня. Я перепроверяю эту проблему с enotconn, так как я не доволен принятым решением. У @tilgovi есть еще одно исправление, которое можно протестировать.

?

вы тестировали другой патч, чтобы он помог?

спасибо, мне интересно знать, есть ли какая-либо информация об обновлении пакета pip?

@yehjames - мастер работает на вас? Релиз запланирован уже сегодня. Но любые отзывы о том, как master работает на разных платформах, приветствуются.

@benoitc Есть поводу ? Использовал 20.0.4 в производстве и реализовал изменение, предложенное @asantoni (как обезьяний-патч), чтобы избежать частых сбоев. Но статическое сканирование кода Veracode не любит патч, поэтому пытаюсь исправить его сейчас. Спасибо!

Мы постараемся выпустить релиз как можно скорее. Мы не можем обещать ни дня, но мы работаем над тем, чтобы выяснить, что осталось от этого выпуска, и над улучшением управления выпусками в будущем.

Пожалуйста, используйте функцию GitHub «Наблюдать» для репозитория и следите за выпусками, если вы хотите получать уведомления.

Привет. У меня такая же проблема с HAProxy + Gunicorn + Django.

Мой бэкэнд HAProxy теряет почти все свои серверы из-за того, что проверки не отвечают, а журналы Gunicorn страдают от:

[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

Я работаю с gunicorn == 20.0.4, Django == 3.1.5, HA-Proxy версии 2.2.11-1ppa1 ~ bionic

Есть какие-нибудь подсказки о том, как действовать дальше?

Это в режиме TCP, без SSL, при стресс-тестировании саранчи.

Кто-нибудь, пожалуйста, поделитесь решением этой проблемы

@krishnamanchikalapudi @ricarhincapie, пожалуйста, обновитесь до последней версии Gunicorn :)