web-dev-qa-db-fra.com

Le script a expiré avant de renvoyer les en-têtes: wsgi.py sur un haricot élastique

J'essaie de déployer une application Django sur Elastic Beanstalk. Quand je visite la page, elle ne se charge jamais. Les journaux disent:

Script timed out before returning headers: wsgi.py

Je peux ssh sur le serveur et exécuter manage.py runserver puis curl 127.0.0.1:8000 à partir d'un autre terminal, ce qui renverra la page. Donc, je suppose que cela doit être un problème avec la configuration Apache qui est configurée dans Elastic Beanstalk.

Voici plus de journaux:

[pid 15880] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[so:warn] [pid 15880] AH01574: module wsgi_module is already loaded, skipping
[auth_digest:notice] [pid 15880] AH01757: generating secret for digest authentication ...
[lbmethod_heartbeat:notice] [pid 15880] AH02282: No slotmem from mod_heartmonitor
[mpm_prefork:notice] [pid 15880] AH00163: Apache/2.4.9 (Amazon) mod_wsgi/3.4 Python/2.7.5       configured -- resuming normal operations
[core:notice] [pid 15880] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[:error] [pid 15881] /opt/python/run/venv/lib/python2.7/site-packages/numpy/oldnumeric/__init__.py:11: ModuleDeprecationWarning: The oldnumeric module will be dropped in Numpy 1.9
[:error] [pid 15881]   warnings.warn(_msg, ModuleDeprecationWarning)
[:error] [pid 15881] 
[core:error] [pid 15884] [client 10.248.110.45:58996] Script timed out before returning headers: wsgi.py

Et mon fichier wsgi.py:

import os
os.environ.setdefault("Django_SETTINGS_MODULE", "aurora.settings")

from Django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Des indices sur ce qui pourrait causer cela?

METTRE À JOUR:

J'ai reconstruit mon environnement et j'ai à nouveau rencontré ce problème. J'ai mis à jour /etc/httpd/conf.d/wsgi.conf pour inclure WSGIApplicationGroup %{GLOBAL}comme mentionné ici . J'utilise Scipy, Numpy et GeoDjango (qui utilise GDAL). Je sais que GDAL n'est pas entièrement thread-safe et je ne suis pas sûr des autres, mais je suppose que c'était un problème de sécurité des threads.

djangoapachemod-wsgiwsgielastic-beanstalk
15
Meistro

MISE À JOUR 8 FEV 2017

Auparavant, mon wsgi.conf n'utilisait qu'un processus:

WSGIDaemonProcess wsgi process = 1 threads = 15 display-name =% {GROUP}

J'ai augmenté le processus à quelque chose de plus raisonnable et n'ai eu aucun problème:

WSGIDaemonProcess wsgi process = 6 threads = 15 display-name =% {GROUP}

Ce changement, ainsi que l'ajout original de WSGIApplicationGroup %{GLOBAL}, semblent avoir fait l'affaire.

MISE À JOUR 17 septembre 2015

Je rencontre encore parfois ce problème. Généralement, le redéploiement via eb deploy résout le problème. Il est difficile de dire quel est le problème sous-jacent.

Réponse originale

Le projet a finalement fonctionné, mais j'ai ensuite essayé de créer une image à utiliser pour les nouvelles instances, ce qui a rouvert le problème. Je ne suis pas sûr de savoir pourquoi cela a fonctionné, puis il a cessé de fonctionner, mais j'ai reconstruit mon AMI personnalisée à partir de rien, puis j'ai repoussé mon projet. Il s'avère que c'était un problème dans wsgi.py. La version que j'ai publiée était en réalité différente de ce qui était en train d'être déployé. Pour une raison quelconque, un autre développeur avait mis ceci dans wsgi.py:

path = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
if path not in sys.path:
sys.path.append(path)

J'ai enlevé ceci et cela a résolu le problème.

Mon conseil pour tous ceux qui ont

Script timed out before returning headers: wsgi.py

est de vérifier votre fichier wsgi.py.

9
Meistro

Cela semble certainement être un problème avec WSGI et Apache, comme vous l'avez mentionné. Une chose à vérifier est le fichier .ebextensions dans votre répertoire source.

Il devrait y avoir une config qui spécifie les informations WSGI comme l'emplacement de l'application. Vous pouvez également vérifier vos paramètres Django et l’exécuter localement avec une configuration Apache utilisant WSGI.

Vous avez probablement déjà déjà lu la documentation officielle de WSGI et de Django, mais il est possible que vous ayez oublié des choses simplistes: http://docs.aws.Amazon.com/elasticbeanstalk/latest/dg/create_deploy_Python_Django.html #create_deploy_Python_Django_update

4
Josh Davis

Pour nous, le correctif consistait à ajouter le paramètre WSGIApplicationGroup %{GLOBAL} conformément à la réponse de Meistro .

Vous voudrez vous assurer que vous modifiez votre configuration wsgi à l'aide de votre fichier .ebextensions/foobar.config, afin que les modifications soient permanentes. Voir la documentation de .ebextensions .

Ajoutez les éléments suivants à votre fichier .ebextensions/foobar.config:

files:
  "/etc/httpd/conf.d/wsgi_custom.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      WSGIApplicationGroup %{GLOBAL}

Cela créera (ou écrasera) le contenu du fichier /etc/httpd/conf.d/wsgi_custom.conf avec WSGIApplicationGroup %{GLOBAL}

3
Chris W.

Juste mes 2 cents sur un problème similaire, j'ai fait face.

J'avais un problème similaire. Il s’est avéré que le script (qui effectue un appel de base de données à l’insertion, à la mise à jour et à la suppression) en cours d’exécution à partir de l’application Django attendait dans un état bloqué que le verrou de la table soit libéré. Une fois publié, le code est passé sans cette erreur. Je n'ai jamais eu à redéployer mon application EB.

  1. Assurez-vous que vous n'êtes pas connecté à la base de données via un autre client SQL. Si oui, recherchez les verrous actifs. (Dans mon cas, je me connectais à redshift. L'interrogation du tableau STV_LOCKS répertorie les verrous actifs).
  2. Vérifiez qui détient les serrures. (Dans mon cas, c’était mon client SQL, connecté à redshift, qui exécutait une opération CUD, et comme COMMIT n’était pas émis, il contenait un verrou d’écriture en attente sur la table).
  3. J'ai émis une validation de mon client SQL, et le verrou a été libéré. Mon code EB a traversé et il n'y avait plus d'erreur de délai d'expiration du script.
3
Kris

J'ai essayé les étapes ci-dessus qui peuvent résoudre le problème temporellement. alors j'ai fait les étapes suivantes:

  1. créer le fichier "packages.config" sous le dossier ".ebextensions" et mettre les lignes suivantes

    WSGIApplicationGroup: command: grep -rnw 'WSGIApplicationGroup' config.py || sed -i.bak '/LogFormat/ a WSGIApplicationGroup %%{GLOBAL}' config.py cwd: /opt/elasticbeanstalk/hooks

merci pour aide à faire cela qui donné suggestion pour ce type d'erreur

J'ai finalement fixé. venez de lire sur le concept de module de chargement Apache mpm

J'ai changé le mode de chargement par défaut du module Apache preforker (mon cas) qui dépend de l'OS.

trouver ci-dessous l'emplacement

location: /etc/httpd/conf.module.d/00-mpm*.

Activer le module travailleur qui dépend de nos cas

LoadModule mpm_worker_module lib64/httpd/modules/mod_mpm_worker.so

encore une fois merci pour qui m'a aidé.

0
selvasundarraj