web-dev-qa-db-fra.com

WSGI: en-têtes de réponse tronqués ou surdimensionnés reçus du processus démon

Configuration système: 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/

Je ne connais pas la cause de l'erreur. Mais je l'ai réduit au processus Django wsgi. Puisque le serveur héberge correctement les fichiers statiques.

Alors que Cloudflare affiche parfois 502: erreur de passerelle incorrecte, le serveur lui-même affiche 500: erreur de serveur interne.

J'ai déjà essayé de redémarrer le serveur et de vérifier le fichier journal (de débogage) de Django. Il n'y a aucune information d'erreur dans les fichiers journaux Django (pas du tout).

Comment dois-je déboguer le problème? Puisque Django n'a rien enregistré, je suppose que le problème pourrait être causé dans wsgi.

Remarque: le serveur fonctionnait correctement auparavant. J'ai apporté quelques modifications * (qui sont rétablies telles quelles); Le shell Django fonctionne bien.

Modifications *

  1. Django-pandas installé, Django-model-utils, numpy, scikit-learn
  2. Un programme qui utilise les bibliothèques ci-dessus. (Ce changement revient à l'original)

Dans d'autres questions similaires, le problème est causé lors du téléchargement d'un gros fichier.

djangomod-wsgiapache2
10
Suraj

La cause du problème était numpy.

Les modules d'extension Python C, comme numpy, sont connus pour provoquer des délais d'attente lorsqu'ils sont utilisés sous mod_wsgi.

Source: Réponse de Sean F on Délai d'expiration lors de la lecture des en-têtes de réponse du processus démon

Une question similaire à laquelle je n'ai pas trouvé lors de la recherche initiale a répondu et expliquée par l'auteur de mod_wsgi dit -

Certains packages tiers pour Python qui utilisent des modules d'extension C, et cela inclut scipy et numpy, ne fonctionneront que dans l'interpréteur principal Python et ne peuvent pas être utilisés dans sous-interprètes comme mod_wsgi par défaut utilise. Le résultat peut être un blocage de thread, un comportement incorrect ou des plantages de processus.

Source: Réponse de Graham Dumpleton sur Apache non réactif + mod_wsgi après l'installation de scipy

Solution

Ajoutez la ligne ci-dessous à votre httpd.conf. Dans mon cas, le fichier était /etc/Apache2/Apache2.conf.

WSGIApplicationGroup %{GLOBAL}
8
Suraj

Comme d'autres l'ont mentionné, cela est dû au plantage du processus pour un certain nombre de raisons potentielles. Une des raisons étant que certaines dépendances Python ne sont pas thread-safe).

Si c'est le problème, une solution consiste à changer le type MPM d'Apache. Le type prefork n'utilise pas de threads, donc si le problème se bloque numpy en raison d'une mauvaise utilisation du thread, cela devrait le résoudre. Les types de travail et d'événement utilisent moins de mémoire, mais utilisent également des threads, afin qu'ils puissent rencontrer cette erreur.

Pour déterminer le type que vous utilisez actuellement, exécutez:

apachectl -V | grep -i mpm

Si tu vois Server MPM: prefork vous utilisez déjà prefork, ce qui signifie que la cause de l'erreur peut être autre chose. S'il indique "travailleur" ou "événement", vous pouvez basculer vers prefork en exécutant:

Sudo a2dismod mpm_event
Sudo a2dismod mpm_worker
Sudo a2enmod mpm_prefork
Sudo service Apache2 restart

Notez que le principal inconvénient de prefork est que, puisqu'il n'utilise pas de threads, il consomme plus de mémoire.

Edit: j'ai depuis rencontré cette erreur pour d'autres raisons. Plus récemment, le problème est dû à un bogue dans le paquet système mod-wsgi précompilé d'Ubuntu ainsi qu'à un bogue dans le paquet Python psycopg2).

La solution pour cela était de passer du système mod-wsgi au package Python, ainsi que de passer au package psycopg2-binary:

Sudo apt purge libapache2-mod-wsgi*
Sudo apt install Apache2-dev
pip uninstall psycopg2
pip install mod_wsgi psycopg2-binary

J'ai également dû mettre à jour mon fichier de configuration de site Apache en ajoutant en haut:

LoadModule wsgi_module /usr/local/myproject/.env/lib/python2.7/site-packages/mod_wsgi/server/mod_wsgi-py27.so

Et changez mon instruction WSGIDaemonProcess pour utiliser python-home au lieu de python-path, en quelque chose comme:

WSGIDaemonProcess myproject python-home=/usr/local/myproject/.env processes=5 threads=15 display-name=%{GROUP} user=www-data group=www-data

J'ai rencontré cela pour Python2.7 et Python3.7 et la solution est la même, mais le chemin vers le mod_wsgi.so change.

6
Cerin

J'ai reçu une erreur similaire en essayant d'exécuter opencv en utilisant mod_wsgi et Apache. Je suppose que le problème était probablement plusieurs threads avec du code C sous-jacent essayant d'acquérir GIL et échouant.

Je l'ai résolu en définissant threads = 1 et process = 32 (dans mon cas, c'était approprié) dans la directive WSGIDaemonProcess.

PS: Tard dans la soirée mais j'ai pensé que ça pourrait aider quelqu'un.

2
mind_stone

Je l'ai obtenu de Python accès à magic (libmagic). Certaines versions de magic se comportent comme ça. Je viens de compiler une version et utilisé au lieu de celui fourni avec le système d'exploitation, pour une raison qui l'a résolu.

0
Amichai Schreiber

Dans mon cas, j'ai dû changer la ligne 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

à:

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

Dans mon cas, le problème était pymongo et PHP . Comme décrit dans ce numéro GitHub https://github.com/GrahamDumpleton/mod_wsgi/issues/351 :

Si PHP charge un client pour MongoDB, il peut [créer un conflit]. (...) PHP précharge souvent toutes les extensions. Peu importe si l'application hébergée l'utilise ou non.

La façon dont je l'ai résolu:

  1. J'ai exécuté mon flask app de mod_wsgi-express: mod_wsgi-express start-server api.wsgi --user=www-data --group=www-data --Host=0.0.0.0 --port=8443.
  2. Ensuite, dans mon httpd.conf, J'ai redirigé tout le trafic vers mon flask alias d'application en utilisant:
SSLEngine on
SSLProxyEngine On
ProxyPass /api http://localhost:8443/
ProxyPassReverse /api http://localhost:8443/
0
prm296