Timeout für Skript vor der Rückkehr Header: wsgi.py auf elastic beanstalk

Ich versuche zum bereitstellen einer Django-Anwendung zu Elastic Beanstalk. Wenn ich Besuch die Seite nie lädt. Die Protokolle sagen:

Script timed out before returning headers: wsgi.py

Kann ich ssh in den server, und führen Sie manage.py runserver und dann curl 127.0.0.1:8000 von einem anderen terminal, wird wieder die Seite erfolgreich. Also ich nehme an es muss ein Problem mit der Apache-Konfiguration, die eingerichtet ist, als Teil der Elastic Beanstalk.

Ist hier eher die logs:

[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

Und meine wsgi.py Datei:

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

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

Irgendwelche Hinweise darauf, was könnte die Ursache sein?

UPDATE:

Ich baute meine Umgebung und lief in dieses Problem wieder. Ich aktualisiert /etc/httpd/conf.d/wsgi.conf zu gehören WSGIApplicationGroup %{GLOBAL} wie hier erwähnt. Ich bin mit Scipy, Numpy und GeoDjango (mit GDAL). Ich weiß, GDAL ist nicht vollständig thread-sicher, und ich bin mir nicht sicher über die anderen, aber ich nehme an, es war ein thread Frage der Sicherheit.

InformationsquelleAutor der Frage Meistro | 2014-08-24

9

UPDATE 8 FEB 2017

Zuvor meine wsgi.conf wurde nur mit einem Prozess:

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

Ich steigerte die Prozesse um etwas vernünftiger und habe keine Probleme:

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

Diese änderung zusammen mit dem original neben der WSGIApplicationGroup %{GLOBAL} scheint getan haben, der trick.

UPDATE 17. September 2015

Ich bin immer noch gelegentlich laufen, um zu diesem Thema. In der Regel, die Versetzung von über eb deploy behebt das Problem. Es ist schwer zu sagen, was das zugrunde liegende Problem ist.

Ursprüngliche Antwort

Schließlich bekam ich das Projekt arbeiten, aber dann versucht, ein Bild zu schaffen für neue Instanzen, was wieder das problem. Ich bin mir nicht sicher, warum funktionierte es dann aufgehört zu arbeiten, aber ich baute meine benutzerdefinierte AMI, das von Grund auf neu und dann repushed mein Projekt. Stellt sich heraus, es war ein Problem in wsgi.py. Die version, die ich gepostet war eigentlich das, was anders war, die bereitgestellt werden. Für einige Grund ein anderer Entwickler hatte dies in wsgi.py:
```
path = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
if path not in sys.path:
sys.path.append(path)
```
Ich entfernt und das problem behoben.

Mein Rat für jedermann mit
```
Script timed out before returning headers: wsgi.py
```
ist zu prüfen, ob Sie wsgi.py Datei.

InformationsquelleAutor der Antwort Meistro
4

Es sicher scheint, wie ein Problem mit WSGI und Apache wie du Sie erwähnt hast. Eine Sache zu überprüfen ist .ebextensions-Datei im Quellverzeichnis.

Sollte es eine config gibt, gibt das WSGI-Informationen wie den Speicherort der Anwendung. Möglicherweise möchten Sie auch prüfen, Ihre Django-Einstellungen, und führen Sie es lokal mit Apache-Server mit WSGI.

Wahrscheinlich haben Sie bereits Lesen Sie die offizielle Dokumentation für WSGI und Django, aber vielleicht fangen einige vereinfachende Dinge, die Sie vielleicht übersehen haben: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Python_django.html#create_deploy_Python_django_update

InformationsquelleAutor der Antwort Josh Davis
2

Nur meine 2 Cent auf ein ähnliches Problem, das ich konfrontiert.

Ich hatte ein ähnliches problem. Es stellte sich heraus, dass das Skript (das macht ein DB-insert/update/delete-Aufruf) ausgeführt wird, von der django-Anwendung war das warten in einem deadlock-Zustand für die Sperre auf der Tabelle freigegeben werden. Sobald es freigegeben wurde, wird der code ging durch ohne diesen Fehler. Ich hatte nie erneut bereitstellen meine EB-Anwendung.
1. Stellen Sie sicher, dass Sie nicht mit der Datenbank verbunden, die durch eine andere SQL-client. Wenn ja, Abfrage für alle aktiven sperren. (In meinem Fall, ich war die Verbindung zu Rotverschiebung. Abfragen STV_LOCKS Tabelle listet die aktiven sperren).
2. Überprüfen, wer hält die Schlösser. (In meinem Fall war es mein SQL-client, verbunden, um die Rotverschiebung, die Ausführung einer CUDA-Betrieb, und da BEGEHEN, war nicht ausgestellt, es wurde die Abhaltung einer ausstehenden Schreibsperre auf die Tabelle).
3. Gab ich ein commit aus meiner SQL-client, und die Sperre freigegeben wurde. Meine EB code durchgegangen und es gab keine Skript-Fehlermeldung Zeitüberschreitung nicht mehr.
InformationsquelleAutor der Antwort Kris
2

Das Update war für uns die Beurteilung der WSGIApplicationGroup %{GLOBAL} Einstellung wie pro Meistro Antwort.

Werden Sie sicherstellen wollen, Bearbeiten Sie Ihre wsgi config durch Ihre .ebextensions/foobar.config - Datei, damit die änderungen permanent sind. Siehe die .ebextensions config-docs.

Fügen Sie den folgenden, um Ihre .ebextensions/foobar.config Datei:
```
files:
  "/etc/httpd/conf.d/wsgi_custom.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      WSGIApplicationGroup %{GLOBAL}
```
Diese erstellen (oder überschreiben) wird der Inhalt der /etc/httpd/conf.d/wsgi_custom.conf - Datei mit WSGIApplicationGroup %{GLOBAL}

InformationsquelleAutor der Antwort Chris W.
0

Ich habe versucht oben genannten Schritte das Problem lösen kann zeitlich. dann habe ich getan Balg Schritte:
1. machen " - Pakete.config" - Datei unter ".ebextensions " - Ordner und setzen Sie folgende Zeilen
  
  WSGIApplicationGroup: command: grep -rnw 'WSGIApplicationGroup' config.py || sed -i.bak '/LogFormat/a WSGIApplicationGroup %%{GLOBAL}' config.py cwd: /opt/elasticbeanstalk/hooks
Dank für die hilft, um aus diesem die Anregung gegeben, die für diese Art von Fehler

Habe ich endlich behoben. Lesen Sie einfach über das apache mpm Modul geladen Konzept

Ich geändert wurde die Standard-load-Modus von apache preforker(mein Fall) - Modul ist, hängt von os.

finden unter location

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

Aktivieren worker-Modul, das hängt in unserem Fall,

LoadModule mpm_worker_module lib64/httpd/modules/mod_mpm_worker.so

wieder einmal vielen Dank für die mir geholfen haben.

InformationsquelleAutor der Antwort selvasundarraj

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.