Estou tendo esse problema na imagem do raspbian
[2018-09-10 20:40:11 +0800] [21421] [CRÍTICO] TEMPO LIMITE DO TRABALHADOR (pid: 21699)
[2018-09-10 20:40:11 +0800] [21699] [ERROR] Solicitação de processamento de erro de soquete.
Traceback (última chamada mais recente):
Arquivo "/usr/lib/python3/dist-packages/gunicorn/workers/async.py", linha 62, no identificador
six.reraise (* sys.exc_info ())
Arquivo "/usr/lib/python3/dist-packages/gunicorn/six.py", linha 625, em reraise
aumentar o valor
Arquivo "/usr/lib/python3/dist-packages/gunicorn/workers/async.py", linha 35, no identificador
listener_name = listener.getsockname ()
OSError: [Errno 9] Descritor de arquivo incorreto
@ leond08 Obrigado pelo ingresso!
Para entender como isso está acontecendo, você pode fornecer um pouco mais de informação?
Estou usando a versão mais recente do gunicorn3
Estou usando eventlet e gevent para isso
Estou executando meu aplicativo Flask - Flask-SocketIO
Eu inicio minha tarefa em segundo plano depois que um usuário clica no botão
Minha função de tarefa em segundo plano é ouvir um evento,
depois de clicar no botão "CONCLUÍDO", a tarefa em segundo plano deve parar
em seguida, envie uma mensagem de emissão para todos os usuários
Tive o mesmo problema com aiohttp + gunicorn, observe a mesma mensagem sempre que ctrl + c.
[INFO] Erro ao fechar o soquete [Errno 9] Descritor de arquivo incorreto
Eu não o reproduzo. Suspeito que seu aplicativo esteja fechando alguns fds que criam o problema acima.
Estamos enfrentando o mesmo problema, mas isso só está acontecendo em 1 de 8 contêineres em execução no docker swarm.
Tivemos o mesmo problema com 1 de 9 contêineres. Parece que está relacionado a docker, python3 e gevent.
gunicorn 20.0.4 + aiohttp 3.6.2
Gunicorn está sendo executado como servidor de desenvolvimento:
gunicorn --reload app:make_app --bind localhost:5000 --worker-class aiohttp.GunicornWebWorker --workers 2 --access-logfile -
Quase todo Ctrl + C termina com
^C[2020-05-23 21:49:50 +0200] [38524] [INFO] Handling signal: int
Exception ignored when trying to write to the signal wakeup fd:
Exception ignored when trying to write to the signal wakeup fd:
Traceback (most recent call last):
File "/usr/lib/python3.8/asyncio/unix_events.py", line 42, in _sighandler_noop
Traceback (most recent call last):
File "/usr/lib/python3.8/asyncio/unix_events.py", line 42, in _sighandler_noop
def _sighandler_noop(signum, frame):
def _sighandler_noop(signum, frame):
OSError: [Errno 9] Bad file descriptor
OSError: [Errno 9] Bad file descriptor
[2020-05-23 21:49:50 +0200] [38526] [INFO] Worker exiting (pid: 38526)
[2020-05-23 21:49:50 +0200] [38528] [INFO] Worker exiting (pid: 38528)
[2020-05-23 21:49:50 +0200] [38524] [INFO] Shutting down: Master
Não importa se o aplicativo tratou de alguma solicitação ou não.
Com Sanic 20.3.0:
^C[2020-05-26 13:24:55 +0200] [27706] [INFO] Handling signal: int
[2020-05-26 13:24:55 +0200] [27769] [INFO] Stopping server: 27769, connections: 0
[2020-05-26 13:24:55 +0200] [27769] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-05-26 13:24:55 +0200] [27769] [INFO] Worker exiting (pid: 27769)
[2020-05-26 13:24:55 +0200] [27771] [INFO] Stopping server: 27771, connections: 0
[2020-05-26 13:24:55 +0200] [27771] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-05-26 13:24:55 +0200] [27771] [INFO] Worker exiting (pid: 27771)
[2020-05-26 13:24:55 +0200] [27706] [INFO] Shutting down: Master
O mesmo aqui com a classe de trabalho Gunicorn 20.0.4 + Uvicorn 0.11.5 em cada Ctrl + C
INFO: [12621] [gunicorn.error] Handling signal: int
INFO: [12635] [gunicorn.error] Error while closing socket [Errno 9] Bad file descriptor
INFO: [12634] [gunicorn.error] Error while closing socket [Errno 9] Bad file descriptor
INFO: [12635] [gunicorn.error] Worker exiting (pid: 12635)
INFO: [12634] [gunicorn.error] Worker exiting (pid: 12634)
INFO: [12621] [gunicorn.error] Shutting down: Master
algum exemplo de aplicação? Além disso, de qual versão do Python estamos falando?
Ubuntu 20.04, sistema fornecido Python 3.8.2 em virtualenv
Aplicativo de exemplo: https://github.com/zgoda/newsloop-server/tree/d603a1c10c9e8be3d998f62ccc55dd73f4677115 (com aiohttp) ou https://github.com/zgoda/newsloop-server/tree/b2a8a7f09cfa51b548b037f09c5b548a7f09c09848b037f09c098b0384b548e037f09c098bc0384b548e0384bc098b8a7384f098bc037bbc0384bc098b8a7384f9c098a8a8458c0384bc0384bc0384bc0384b5a8a7f09c098a8a7385f9c098a8a8a7f09c4f9c098a8a8a7f09c09848 Invocação exata do gunicorn em meu comentário anterior.
As diferenças na produção entre aiohttp e Sanic me fazem suspeitar de que há algo errado envolvendo os trabalhadores.
Mesmo problema, python 3.8.0
sanic 19.12.2
gunicorn 20.0.4
Edit: isso acontece quando eu executo localmente no meu Mac, mas não quando executo dentro de uma docker Linux, pode ajudá-lo
Olá,
Acho que esse problema https://github.com/benoitc/gunicorn/issues/2064 tem os mesmos motivos.
Temos quase os mesmos erros do problema, mas usamos gunicorn - 19.9.0
Também estou experimentando isso, FastAPI + os últimos trabalhadores Gunicorn e uvicorn com Python 3.8.5
Assim que eu parar de usar o uvicorn (ou seja, remover esta linha da minha configuração do gunicorn):
worker_class = "uvicorn.workers.UvicornWorker"
Os erros desaparecem.
Conforme descrito acima, isso acontece ao parar o Gunicorn com Ctrl + C ou enviar um sinal de eliminação elegante para o PID.
[2020-09-12 11:56:37 +1000] [100390] [INFO] Starting gunicorn 20.0.4
[2020-09-12 11:56:37 +1000] [100390] [INFO] Listening at: http://0.0.0.0:6000 (100390)
[2020-09-12 11:56:37 +1000] [100390] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-09-12 11:56:37 +1000] [100392] [INFO] Booting worker with pid: 100392
[2020-09-12 11:56:38 +1000] [100392] [INFO] Started server process [100392]
[2020-09-12 11:56:38 +1000] [100392] [INFO] Waiting for application startup.
[2020-09-12 11:56:38 +1000] [100392] [INFO] Application startup complete.
[2020-09-12 11:56:48 +1000] [100390] [INFO] Handling signal: term
[2020-09-12 11:56:48 +1000] [100392] [INFO] Shutting down
[2020-09-12 11:56:48 +1000] [100392] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-09-12 11:56:48 +1000] [100392] [INFO] Waiting for application shutdown.
[2020-09-12 11:56:48 +1000] [100392] [INFO] Application shutdown complete.
[2020-09-12 11:56:48 +1000] [100392] [INFO] Finished server process [100392]
[2020-09-12 11:56:48 +1000] [100392] [INFO] Worker exiting (pid: 100392)
[2020-09-12 11:56:48 +1000] [100390] [INFO] Shutting down: Master
Aqui está uma réplica exata do problema:
[fots<strong i="6">@workstation</strong> testing]$ python3.8 -V
Python 3.8.5
[fots<strong i="7">@workstation</strong> testing]$ python3.8 -m venv ~/.virtualenv/testing
[fots<strong i="8">@workstation</strong> testing]$ source ~/.virtualenv/testing/bin/activate
(testing) [fots<strong i="9">@workstation</strong> testing]$ pip install fastapi gunicorn uvicorn
Collecting fastapi
Using cached fastapi-0.61.1-py3-none-any.whl (48 kB)
Collecting gunicorn
Using cached gunicorn-20.0.4-py2.py3-none-any.whl (77 kB)
Collecting uvicorn
Using cached uvicorn-0.11.8-py3-none-any.whl (43 kB)
Collecting pydantic<2.0.0,>=1.0.0
Using cached pydantic-1.6.1-cp38-cp38-manylinux2014_x86_64.whl (11.5 MB)
Collecting starlette==0.13.6
Using cached starlette-0.13.6-py3-none-any.whl (59 kB)
Requirement already satisfied: setuptools>=3.0 in /home/fots/.virtualenv/testing/lib/python3.8/site-packages (from gunicorn) (47.1.0)
Collecting h11<0.10,>=0.8
Using cached h11-0.9.0-py2.py3-none-any.whl (53 kB)
Collecting websockets==8.*
Using cached websockets-8.1-cp38-cp38-manylinux2010_x86_64.whl (78 kB)
Collecting httptools==0.1.*; sys_platform != "win32" and sys_platform != "cygwin" and platform_python_implementation != "PyPy"
Using cached httptools-0.1.1-cp38-cp38-manylinux1_x86_64.whl (227 kB)
Collecting uvloop>=0.14.0; sys_platform != "win32" and sys_platform != "cygwin" and platform_python_implementation != "PyPy"
Using cached uvloop-0.14.0-cp38-cp38-manylinux2010_x86_64.whl (4.7 MB)
Collecting click==7.*
Using cached click-7.1.2-py2.py3-none-any.whl (82 kB)
Installing collected packages: pydantic, starlette, fastapi, gunicorn, h11, websockets, httptools, uvloop, click, uvicorn
Successfully installed click-7.1.2 fastapi-0.61.1 gunicorn-20.0.4 h11-0.9.0 httptools-0.1.1 pydantic-1.6.1 starlette-0.13.6 uvicorn-0.11.8 uvloop-0.14.0 websockets-8.1
WARNING: You are using pip version 20.1.1; however, version 20.2.3 is available.
You should consider upgrading via the '/home/fots/.virtualenv/testing/bin/python3.8 -m pip install --upgrade pip' command.
(testing) [fots<strong i="10">@workstation</strong> testing]$ ls -l
total 4
-rw-rw-r-- 1 fots fots 117 Sep 12 12:13 main.py
(testing) [fots<strong i="11">@workstation</strong> testing]$ cat main.py
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
async def root():
return {"message": "Hello World"}
(testing) [fots<strong i="12">@workstation</strong> testing]$ gunicorn -k uvicorn.workers.UvicornWorker main:app
[2020-09-12 12:19:05 +1000] [105788] [INFO] Starting gunicorn 20.0.4
[2020-09-12 12:19:05 +1000] [105788] [INFO] Listening at: http://127.0.0.1:8000 (105788)
[2020-09-12 12:19:05 +1000] [105788] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-09-12 12:19:05 +1000] [105790] [INFO] Booting worker with pid: 105790
[2020-09-12 12:19:05 +1000] [105790] [INFO] Started server process [105790]
[2020-09-12 12:19:05 +1000] [105790] [INFO] Waiting for application startup.
[2020-09-12 12:19:05 +1000] [105790] [INFO] Application startup complete.
^C[2020-09-12 12:19:06 +1000] [105788] [INFO] Handling signal: int
[2020-09-12 12:19:06 +1000] [105790] [INFO] Shutting down
[2020-09-12 12:19:06 +1000] [105790] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-09-12 12:19:06 +1000] [105790] [INFO] Waiting for application shutdown.
[2020-09-12 12:19:06 +1000] [105790] [INFO] Application shutdown complete.
[2020-09-12 12:19:06 +1000] [105790] [INFO] Finished server process [105790]
[2020-09-12 12:19:06 +1000] [105790] [INFO] Worker exiting (pid: 105790)
[2020-09-12 12:19:07 +1000] [105788] [INFO] Shutting down: Master
E aqui está a saída de pip freeze
:
click==7.1.2
fastapi==0.61.1
gunicorn==20.0.4
h11==0.9.0
httptools==0.1.1
pydantic==1.6.1
starlette==0.13.6
uvicorn==0.11.8
uvloop==0.14.0
websockets==8.1
Tentei instalar o uvicorn e o gunicorn do GitHub (branch master) para garantir que recebi as correções mais recentes, mas o problema persistiu.
Espero que isto ajude
Fotis
gunicorn
e uvicorn
. Esta mensagem de erro começa a ocorrer com uvicorn==0.11.4
e não com a versão anterior 0.11.3
(tanto no OSx quanto em um contêiner Linux). Isso é consistente com os relatórios acima com o uvicórnio, onde as versões relatadas são sempre maiores que 0.11.4
. Provas no finaluvicorn
starlette
e fastapi
no topo da pilha gunicorn+uvicorn
conforme relatado acima; - executa a última versão do uvicórnio 12.X
vez de 0.11.4
; - executa gunicorn
com mais de um trabalhador uvicorn
Provas Em uma nova pasta no osx, execute o script anexado test.sh
(testado no osx). Para testar no contêiner Linux, salve o script e o Dockerfile e, a seguir, leia o cabeçalho do Dockerfile. Também anexei o log do script.
@benoitc , o que você acha deste commit em uvicorn
que parece introduzir o bug? O problema parece estar na interface entre gunicorn
e uvicorn
. Você pode comentar sobre a ordem dos 2 blocos de código alterados no commit mencionado acima em uvicorn
? Isso pode ajudar a descobrir por que isso também acontece com os outros casos. Até agora, isso foi relatado também com aiohttp
, gevent
, Flask-SocketIO
sanic
. Anexei também o log do script para facilitar.
arquivo _test.sh_
#!/bin/bash
python3 -m venv venv
source venv/bin/activate
pip install gunicorn==20.0.04 uvicorn==0.11.4
# create simple uvicorn app
printf "async def app(scope, receive, send):\n await send()\n" > example.py
# spin up gunicorn with 1 uvicorn worker, and then send TERM signal to gunicorn
gunicorn example:app -w 1 -k uvicorn.workers.UvicornWorker &
sleep 5 && pkill -f gunicorn
sleep 1
# you will see 1 log entry like this one:
# [XX] [YY] [INFO] Error while closing socket [Errno 9] Bad file descriptor
printf "\n\n[INFO] if you instead bump down uvicorn's version from 11.4 to 11.3 [Errno 9] goes away:\n\n"
pip install uvicorn==0.11.3
gunicorn example:app -w 1 -k uvicorn.workers.UvicornWorker &
sleep 5 && pkill -f gunicorn
arquivo _Dockerfile_
# run with:
# docker run -it $(docker build -q .)
FROM python:3.8
COPY test.sh .
RUN chmod +x /test.sh
CMD /test.sh
Eu tive exatamente o mesmo problema. Aqui está o meu caso.
Resumo: Estou tentando estabelecer um aplicativo de teste para Django dwebsocket com gunicorn. Quando tento usar o websocket_client para testar o resultado, após fechar o websocket esse erro acontece toda vez.
Ambiente :
Imagem do Docker: python: 3.7
versão python: python3.7.6
gunicorn: version = 20.0.4, work = gevent
Versão do Django: Django == 2.2
versão dwebsocket: 0.5.12
Código:
view.py
from dwebsocket import accept_websocket
<strong i="16">@accept_websocket</strong>
def my_ws(request):
if request.is_websocket():
ws = request.websocket
while True:
msg = ws.wait(timeout=15)
if msg is None:
print('get None message')
break
else:
msg = b'echo :' + msg
ws.send(msg)
print('send ws seccess')
print('websocket close')
urls.py
from websocketInfo.views import my_ws
from django.conf.urls import url
urlpatterns = [
url(r'my_ws/$', my_ws, name='my_ws')
]
websocket_client
from websocket import create_connection
ws = create_connection("ws://127.0.0.1:8080/my_ws/")
print("Sending 'Hello, World'...")
ws.send("Hello, World")
print("Receiving...")
result = ws.recv()
print(result)
ws.close()
print('ws close')
commad para executar o servidor gunicorn
gunicorn MyWebsocket.wsgi -b 0.0.0.0:8000 -w 3 -k gevent
saída de erro
send ws seccess
get None message
websocket close
[2021-01-13 02:43:56 +0000] [101] [ERROR] Socket error processing request.
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 65, in handle
util.reraise(*sys.exc_info())
File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 625, in reraise
raise value
File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 55, in handle
self.handle_request(listener_name, req, client, addr)
File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/ggevent.py", line 143, in handle_request
super().handle_request(listener_name, req, sock, addr)
File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 128, in handle_request
util.reraise(*sys.exc_info())
File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 625, in reraise
raise value
File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 114, in handle_request
resp.write(item)
File "/usr/local/lib/python3.7/site-packages/gunicorn/http/wsgi.py", line 326, in write
self.send_headers()
File "/usr/local/lib/python3.7/site-packages/gunicorn/http/wsgi.py", line 322, in send_headers
util.write(self.sock, util.to_bytestring(header_str, "latin-1"))
File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 286, in write
sock.sendall(data)
File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 523, in sendall
return _socketcommon._sendall(self, data_memory, flags)
File "/usr/local/lib/python3.7/site-packages/gevent/_socketcommon.py", line 367, in _sendall
chunk_size = max(socket.getsockopt(SOL_SOCKET, SO_SNDBUF), 1024 * 1024)
File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 156, in __getattr__
return getattr(self._sock, name)
File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 66, in _dummy
raise OSError(EBADF, 'Bad file descriptor')
OSError: [Errno 9] Bad file descriptor
@ChrisXiaoShu O rastreamento de pilha que você postou nos diz que este objeto de socket específico foi explicitamente fechado no nível Python (é quando gevent usa seu _dummy
para gerar as mesmas exceções que o sistema operacional faz). Isso significa que alguma parte da pilha do seu aplicativo está fechando o soquete antes de retornar a resposta para permitir que o gunicorn cuide disso; no ponto em que o erro ocorre, o gunicorn ainda não tinha enviado cabeçalhos de resposta HTTP.
Tipo o mesmo problema no meu caso, com a diferença que esse erro acontece sem fazer nada. Às vezes após 5 minutos, às vezes após 2 horas ...
Comentários muito úteis
gunicorn
euvicorn
. Esta mensagem de erro começa a ocorrer comuvicorn==0.11.4
e não com a versão anterior0.11.3
(tanto no OSx quanto em um contêiner Linux). Isso é consistente com os relatórios acima com o uvicórnio, onde as versões relatadas são sempre maiores que0.11.4
. Provas no finaluvicorn
starlette
efastapi
no topo da pilhagunicorn+uvicorn
conforme relatado acima; - executa a última versão do uvicórnio12.X
vez de0.11.4
; - executagunicorn
com mais de um trabalhadoruvicorn
Provas Em uma nova pasta no osx, execute o script anexado
test.sh
(testado no osx). Para testar no contêiner Linux, salve o script e o Dockerfile e, a seguir, leia o cabeçalho do Dockerfile. Também anexei o log do script.@benoitc , o que você acha deste commit em
uvicorn
que parece introduzir o bug? O problema parece estar na interface entregunicorn
euvicorn
. Você pode comentar sobre a ordem dos 2 blocos de código alterados no commit mencionado acima emuvicorn
? Isso pode ajudar a descobrir por que isso também acontece com os outros casos. Até agora, isso foi relatado também comaiohttp
,gevent
,Flask-SocketIO
sanic
. Anexei também o log do script para facilitar.log_test.log
arquivo _test.sh_
arquivo _Dockerfile_