Script a expiré avant le retour des en-têtes: wsgi.py sur elastic beanstalk

Je suis en train de déployer une application Django Elastic Beanstalk. Quand je visite la page ne se charge jamais. Les journaux disent:

Script timed out before returning headers: wsgi.py

Je peux faire un ssh sur le serveur et exécuter manage.py runserver et puis curl 127.0.0.1:8000 à partir d'un autre terminal, qui sera de retour la page correctement. Donc je suppose qu'il doit y avoir un problème avec la configuration d'Apache est défini comme une partie de Elastic Beanstalk.

Ici, c'est plus de des 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 wsgi.py fichier:

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

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

Des indices quant à ce qui pourrait être la cause?

Mise à JOUR:

J'ai reconstruit mon environnement et courut à nouveau ce problème. J'ai mis à jour /etc/httpd/conf.d/wsgi.conf inclure WSGIApplicationGroup %{GLOBAL} comme mentionné ici. Je suis à l'aide de Scipy, Numpy, et GeoDjango (qui utilise GDAL). Je sais GDAL n'est pas entièrement thread-safe et je ne suis pas certain que les autres mais je suis en supposant que c'était un fil de sécurité.

Je suis l'aide de pandas et de numpy et eu le même problème. L'ajout de WSGIApplicationGroup %{GLOBAL} résolu le problème - mais manuellement en modifiant le fichier ne résout pas le problème pour les nouveaux beanstalk instances. Pour résoudre ce problème, suivez les étapes décrites dans cette réponse
même ici, après le redémarrage de la beanstalk instance.

OriginalL'auteur Meistro | 2014-08-24

9

MISE À JOUR 8 FÉVRIER 2017

Déjà mon wsgi.conf était seulement en utilisant un processus:

WSGIDaemonProcess wsgi processus=1 threads=15 display-name=%{GROUPE}

J'ai haussé les processus à quelque chose de plus raisonnable et n'ai pas eu de problèmes:

WSGIDaemonProcess wsgi processus=6 threads=15 display-name=%{GROUPE}

Ce changement avec le plus original de WSGIApplicationGroup %{GLOBAL} semble avoir fait le tour.

Mise à JOUR le 17 septembre 2015

Je suis encore de temps en temps en cours d'exécution pour ce problème. Généralement, le redéploiement via eb deploy résout le problème. Il est difficile de dire ce que le problème sous-jacent est.

Réponse Originale À Cette Question

Finalement, j'ai eu de travail sur le projet, mais ensuite essayé de créer une image à utiliser pour la création de nouvelles instances, qui a rouvert ses portes le problème. Je ne sais pas pourquoi il a travaillé ensuite cessé de travailler, mais j'ai reconstruit mon AMI personnalisée à partir de zéro et puis repushed mon projet. Il s'avère que c'était un problème dans wsgi.py. La version que j'ai posté était réellement différent de ce qui était en cours de déploiement. Pour certaines raisons, un autre développeur a mis cela dans wsgi.py:
```
path = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
if path not in sys.path:
sys.path.append(path)
```
Je l'ai enlevé et il a résolu le problème.

Mon conseil pour toute personne ayant
```
Script timed out before returning headers: wsgi.py
```
est à vous de vérifier wsgi.py fichier.

Êtes-vous toujours face à ce problème? Je suis fait d'un déploiement de deux applications sur eb. L'un d'eux a bien fonctionné alors que l'autre (que j'utilise scipy) est confronté à ce problème.
d'où wsgi.py séjour?

OriginalL'auteur Meistro
4

Il n'est certes sembler être un problème avec WSGI et Apache comme vous l'avez mentionné. Une chose à vérifier est les .ebextensions fichier dans votre répertoire source.

Il devrait y avoir une option de configuration qui spécifie le WSGI des informations comme l'emplacement de l'application. Vous pourriez également vouloir vérifier votre Django paramètres et l'exécuter en local avec un serveur Apache à l'aide de WSGI.

Vous avez probablement déjà lu la documentation officielle pour WSGI et Django, mais cela peut rattraper un peu simpliste des choses que vous pourriez avoir oublié: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Python_django.html#create_deploy_Python_django_update

Merci pour la réponse, Josh. WSGI emplacement est correct et j'ai lu les docs. Pour un peu plus de contexte, je suis à l'aide d'un AMI personnalisée et j'ai brièvement avait travailler, mais ensuite j'ai immédiatement essayé de créer une image qui a rompu toute chose de nouveau. Je ne suis pas sûr si vous avez des conseils, puisque vous travaillez sur EBS, mais l'installation de ce qui n'est pas trivial comme Scipy et Numpy est extrêmement douloureux depuis pip install scipy prend beaucoup de temps et finira par timeout. Mais la cuisson d'un AMI personnalisée avec tous les pip paquets semble impossible.
Je suis heureux que vous étiez en mesure de le comprendre. Des acclamations.
Merci pour regarder. Confirmant qu'il s'agissait d'un Apache/WSGI question m'a aidé à me concentrer. Mieux.

OriginalL'auteur Josh Davis
3

Le correctif a été pour nous d'ajouter le WSGIApplicationGroup %{GLOBAL} par Meistro réponse.

Vous voudrez vous assurer que vous modifiez votre wsgi config par le biais de votre .ebextensions/foobar.config fichier, de sorte que les changements sont permanents. Voir la .ebextensions config docs.

Ajouter les éléments suivants à votre .ebextensions/foobar.config fichier:
```
files:
  "/etc/httpd/conf.d/wsgi_custom.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      WSGIApplicationGroup %{GLOBAL}
```
Cela va créer (ou écraser) le contenu de la /etc/httpd/conf.d/wsgi_custom.conf fichier avec WSGIApplicationGroup %{GLOBAL}

OriginalL'auteur Chris W.
2

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

J'ai eu un problème similaire. Il s'est avéré que le script (qui fait un DB insert/update/delete appel) en cours d'exécution d'application django a été en attente dans un état de blocage de la serrure sur la table pour être libéré. Une fois qu'il a été libéré, le code est allé à travers sans cette erreur. Je n'ai jamais eu de re-déployer mon EB application.
1. Assurez-vous que vous n'êtes pas connecté à la base de données par le biais de tout autre client SQL. Si oui, requête pour toutes les activités de serrures. (Dans mon cas, j'étais la connexion à redshift. L'interrogation STV_LOCKS tableau liste les actifs des verrous).
2. Vérifier qui est tenue de les verrous. (Dans mon cas, c'était mon client SQL, connecté à redshift, qui a exécuté un CUD opération, et depuis le COMMIT n'a pas été publiée, elle a été tenue en attente d'un verrou en écriture sur la table).
3. J'ai publié une validation de mon client SQL, et la serrure a été libéré. Mon EB code est allé à travers et il n'y avait aucun Script a expiré erreur.
OriginalL'auteur Kris
0

J'ai essayé les étapes ci-dessus qui peuvent résoudre la question que dans le temps. puis j'ai fait soufflet suit:
1. faire des "paquets.config" fichier ".ebextensions " du dossier 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 l'aide à fait ce qui compte tenu de la suggestion de ce type d'erreur

J'ai enfin résolu. viens de lire sur apache mpm de charger le module concept

J'ai été changé par défaut le mode de charge de apache preforker(mon cas) module dépend de l'os.

trouver ci-dessous l'emplacement

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

Permettre travailleur module de laquelle dépend notre cas

LoadModule mpm_worker_module lib64/httpd/modules/mod_mpm_worker.so

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

OriginalL'auteur selvasundarraj

Vous devez vous connecter pour publier un commentaire.