WSGI: Cabeçalhos de resposta truncados ou superdimensionados recebidos do processo daemon

Question

Configuração do Sistema: Apache2, Django 1.10, Python 3, Ubuntu 16.04 LTS

Django debug=True .

/var/log/apache2/error.log

[52:53.057967] [wsgi:error] [pid 4303] [client 1.1.1.22:24409] Timeout when reading response headers from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.466726] [wsgi:error] [pid 4305] [client 1.1.1.10:9787] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.466729] [wsgi:error] [pid 4304] [client 1.1.1.4:18417] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.466726] [wsgi:error] [pid 4307] [client 1.1.1.22:35116] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.466756] [wsgi:error] [pid 4306] [client 1.1.1.22:19242] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.467164] [wsgi:error] [pid 4336] [client 1.1.1.4:34187] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.467212] [wsgi:error] [pid 4342] [client 1.1.1.22:28212] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py, referer: http://example.org/
[52:58.467282] [wsgi:error] [pid 4331] [client 1.1.1.22:31045] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.467426] [wsgi:error] [pid 4341] [client 1.1.1.70:22784] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py, referer: http://example.org/

Eu não sei a causa do erro. Mas eu reduzi isso ao processo wsgi do Django. Como o servidor está hospedando arquivos estáticos corretamente.

Enquanto o Cloudflare às vezes mostra 502: Bad Gateway Error, o próprio servidor mostra 500: Internal Server Error.

Eu já tentei reiniciar o servidor e verificar o arquivo de log (depuração) do Django. Não há informações de erro nos arquivos de log do Django (de jeito nenhum).

Como devo depurar o problema? Como o Django não registrou nada, presumo que o problema possa ser causado no wsgi.

Nota: o servidor estava funcionando bem antes. Eu fiz algumas alterações * (que são revertidas como estão); O shell do Django funciona bem.

Alterações *

1. django-pandas instalados, django-model-utils, numpy, scikit-learn
2. Um programa que utiliza as bibliotecas acima. (Essa alteração é revertida para original)

Em outras perguntas semelhantes, o problema é causado durante o upload de um arquivo grande.

    

Answer 1

A causa do problema foi numpy .

Python C extension modules, like numpy, are known to cause timeouts when used under mod_wsgi.

Source : Answer by Sean F on Timeout when reading response headers from daemon process

Uma pergunta semelhante que eu não encontrei na pesquisa inicial foi respondida e explicada pelo autor de mod_wsgi says -

Some third party packages for Python which use C extension modules, and this includes scipy and numpy, will only work in the Python main interpreter and cannot be used in sub interpreters as mod_wsgi by default uses. The result can be thread deadlock, incorrect behaviour or processes crashes.

Source : Answer by Graham Dumpleton on Non-responsive apache + mod_wsgi after installing scipy

Solução

Adicione a linha abaixo ao seu httpd.conf . No meu caso, o arquivo era /etc/apache2/apache2.conf .

WSGIApplicationGroup %{GLOBAL}

    

Answer 2

Eu recebi um erro semelhante ao tentar executar o opencv usando mod_wsgi e apache. Eu acho que o problema foi provavelmente vários threads com código C subjacente tentando adquirir GIL e falhando.

Eu resolvi isso definindo threads = 1 e processes = 32 (no meu caso era apropriado) na diretiva WSGIDaemonProcess.

PS: Tarde da festa, mas achei que poderia ajudar alguém.

    

Answer 3

Como outros já mencionaram, isso é causado pela falha do processo por vários motivos potenciais. Uma das razões é que algumas dependências do Python não são seguras para threads.

Se esse é o problema, uma alternativa é mudar o tipo de MPM do Apache. O tipo prefork não usa encadeamentos, então se o problema é um erro numpy devido ao uso incorreto do encadeamento, então isso deve consertá-lo. O trabalhador e os tipos de evento usam menos memória, mas também usam encadeamentos, para que possam encontrar esse erro.

Para determinar qual tipo você está usando atualmente, execute:

apachectl -V | grep -i mpm

Se você vir Server MPM: prefork , você já está usando o prefork, o que significa que a causa do erro pode ser outra. Se disser "trabalhador" ou "evento", você poderá alternar para o prefork executando:

sudo a2dismod mpm_event
sudo a2dismod mpm_worker
sudo a2enmod mpm_prefork
sudo service apache2 restart

Note que a principal desvantagem do prefork é que, como não está usando threads, ele consome mais memória.

    

Answer 4

Eu obtive isso do acesso do Python para magic ( libmagic ). Algumas versões do magic se comportam assim. Eu apenas compilei uma versão e usei isso em vez daquela que veio com o SO, por alguma razão que resolveu isso.

    

Answer 5

No meu caso eu tive que mudar a linha WSGIDaemonProcess de:

WSGIDaemonProcess wsgi processes=2 threads=4 display-name=%{GROUP} \
  python-path=/var/www/appname:/var/www/appname/venv/lib/python2.7/site-packages user=wsgi group=wsgi \
  home=/var/www/appname

para:

WSGIDaemonProcess appname user=wsgi group=wsgi processes=2 threads=4 display-name=%{GROUP} home=/var/www/appname