web-dev-qa-db-de.com

Zeitüberschreitung des Skripts, bevor der Header zurückgegeben wird: wsgi.py auf elastischer Bohnenstange

Ich versuche, eine Django-Anwendung für Elastic Beanstalk bereitzustellen. Wenn ich die Seite besuche, wird sie nie geladen. Die Protokolle sagen:

Script timed out before returning headers: wsgi.py

Ich kann in den Server ssh und manage.py runserver und dann curl 127.0.0.1:8000 von einem anderen Terminal ausführen, wodurch die Seite erfolgreich zurückgegeben wird. Ich gehe also davon aus, dass es ein Problem mit der Apache-Konfiguration geben muss, die als Teil von Elastic Beanstalk eingerichtet wurde.

Hier sind weitere Protokolle:

[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()

Gibt es Hinweise darauf, was dies verursachen könnte?

AKTUALISIEREN:

Ich habe meine Umgebung neu aufgebaut und bin erneut auf dieses Problem gestoßen. Ich habe /etc/httpd/conf.d/wsgi.conf aktualisiert, um WSGIApplicationGroup %{GLOBAL}wie hier erwähnt aufzunehmen. Ich benutze Scipy, Numpy und GeoDjango (das GDAL verwendet). Ich weiß, dass GDAL nicht vollständig threadsicher ist und ich bin mir bei den anderen nicht sicher, aber ich gehe davon aus, dass es sich um ein Thread-Sicherheitsproblem handelt.

15
Meistro

UPDATE 8. FEB 2017

Bisher verwendete mein wsgi.conf nur einen Prozess:

WSGIDaemonProcess wsgi Prozesse = 1 Threads = 15 Anzeigename =% {GROUP}

Ich habe die Prozesse auf etwas Vernünftigeres erhöht und keine Probleme gehabt:

WSGIDaemonProcess wsgi Prozesse = 6 Threads = 15 Anzeigename =% {GROUP}

Diese Änderung zusammen mit der ursprünglichen Hinzufügung von WSGIApplicationGroup %{GLOBAL} scheint den Trick getan zu haben.

UPDATE 17. September 2015

Ich werde gelegentlich immer noch auf diese Ausgabe eingehen. Normalerweise behebt die erneute Bereitstellung über eb deploy das Problem. Es ist schwer zu sagen, was das zugrunde liegende Problem ist.

Ursprüngliche Antwort

Ich habe schließlich das Projekt zum Laufen gebracht, aber dann versucht, ein Image für neue Instanzen zu erstellen, wodurch das Problem erneut aufgetreten ist. Ich bin nicht sicher, warum es dann funktioniert hat, aber ich habe mein benutzerdefiniertes AMI von Grund auf neu erstellt und dann mein Projekt neu erstellt. Es stellte sich heraus, dass es ein Problem in wsgi.py war. Die Version, die ich gepostet habe, war tatsächlich die andere als die, die bereitgestellt wurde. Aus irgendeinem Grund hatte ein anderer Entwickler dies in wsgi.py eingefügt:

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

Ich habe das entfernt und es hat das Problem behoben.

Mein Rat für alle, die

Script timed out before returning headers: wsgi.py

ist es, Sie wsgi.py-Datei zu überprüfen.

9
Meistro

Es scheint mit Sicherheit ein Problem mit WSGI und Apache zu sein, wie Sie es erwähnt haben. Eine Sache, die Sie überprüfen sollten, ist die .ebextensions-Datei in Ihrem Quellverzeichnis.

Dort sollte sich eine Konfiguration befinden, die die WSGI-Informationen wie den Speicherort der Anwendung angibt. Möglicherweise möchten Sie auch Ihre Django-Einstellungen überprüfen und lokal mit einem Apache-Setup unter Verwendung von WSGI ausführen.

Sie haben wahrscheinlich bereits die offizielle Dokumentation für WSGI und Django gelesen, aber dies könnte einige vereinfachende Dinge aufdecken, die Sie möglicherweise übersehen haben: http://docs.aws.Amazon.com/elasticbeanstalk/latest/dg/create_deploy_Python_Django.html #create_deploy_Python_Django_update

4
Josh Davis

Das Problem wurde behoben, indem die Einstellung WSGIApplicationGroup %{GLOBAL} gemäß Meistros Antwort hinzugefügt wurde.

Sie sollten sicherstellen, dass Sie Ihre wsgi-Konfiguration über Ihre .ebextensions/foobar.config-Datei bearbeiten, damit die Änderungen dauerhaft sind. Siehe die .ebextensions Konfigurationsdokumente .

Fügen Sie Ihrer .ebextensions/foobar.config-Datei Folgendes hinzu:

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

Dadurch wird der Inhalt der /etc/httpd/conf.d/wsgi_custom.conf-Datei mit WSGIApplicationGroup %{GLOBAL} erstellt (oder überschrieben).

3
Chris W.

Nur meine 2 Cent für ein ähnliches Problem, mit dem ich konfrontiert war.

Ich hatte ein ähnliches Problem. Es stellte sich heraus, dass das Skript (das einen DB-Aufruf zum Einfügen/Aktualisieren/Löschen ausführt), das von der Django-Anwendung ausgeführt wird, in einem Deadlock-Status auf die Freigabe der Sperre für die Tabelle wartete. Sobald es veröffentlicht wurde, ging der Code ohne diesen Fehler durch. Ich musste meine EB-Anwendung nie erneut bereitstellen.

  1. Stellen Sie sicher, dass Sie nicht über einen anderen SQL-Client mit der Datenbank verbunden sind. Wenn ja, fragen Sie nach aktiven Sperren. (In meinem Fall habe ich eine Verbindung zu Redshift hergestellt. In der Tabelle STV_LOCKS werden die aktiven Sperren aufgelistet.).
  2. Überprüfen Sie, wer die Schlösser hält. (In meinem Fall war es mein mit redshift verbundener SQL-Client, der eine CUD-Operation ausführte, und da COMMIT nicht ausgegeben wurde, hatte er eine ausstehende Schreibsperre für die Tabelle.).
  3. Ich habe ein Commit von meinem SQL-Client ausgegeben und die Sperre wurde aufgehoben. Mein EB-Code ging durch und es gab keinen Fehler mehr bei der Zeitüberschreitung von Skripten.
3
Kris

Ich habe oben Schritte ausprobiert, die das Problem zeitlich lösen können. dann habe ich folgende schritte gemacht:

  1. erstellen Sie die Datei "packages.config" im Ordner ".ebextensions" und fügen Sie die folgenden Zeilen ein

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

vielen Dank für die Hilfe, die diese Art von Fehler vorgeschlagen hat

Ich habe es endlich behoben. Lesen Sie einfach mehr über das Apache mpm-Lademodulkonzept

Ich habe den voreingestellten Lademodus vom Apache Preforker (my case) -Modul geändert, was vom Betriebssystem abhängt.

finden Sie unten den Ort

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

Aktivieren Sie das Worker-Modul, das von unseren Fällen abhängt

LoadModule mpm_worker_module lib64/httpd/modules/mod_mpm_worker.so

nochmals vielen Dank für die Hilfe.

0
selvasundarraj

Ich hatte dieses Problem, bis ich merkte, dass ich eine andere Python Version verwendete. Lassen Sie mich dies erklären. Ich verwendete CentOS 7. Die Standard Python Version) in CentOS 7 ist Python 2.7, aber mein Code verwendet Python 3.6, also habe ich Python 3.6 auf dem gleichen Rechner installiert auf diese Weise:

Sudo yum install centos-release-scl
Sudo yum install rh-python36 rh-python36-python-pip rh-python36-python-virtualenv
scl enable rh-python36 bash

Dann erstellte ich eine virtuelle Umgebung und verwendete sie in WSGI:

    WSGIScriptAlias   / /var/www/myproject/myproject/wsgi.py
    WSGIDaemonProcess myproject python-home=/var/www/myproject python-path=/var/www/myproject:/var/www/myproject/lib/python3.6/site-packages
    WSGIProcessGroup  myproject    

Und das Problem "Zeitüberschreitung des Skripts" ist aufgetreten. Dann stelle ich fest, dass die mod_wsgi.so gegen libpython2.7.so.1.0 kompiliert wurde.

# ldd /usr/lib64/httpd/modules/mod_wsgi.so
linux-vdso.so.1 =>  (0x00007ffd3fcae000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f1240cd4000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1240ab8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f12408b3000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f12406b0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f12403ae000)
libc.so.6 => /lib64/libc.so.6 (0x00007f123ffe0000)
/lib64/ld-linux-x86-64.so.2 (0x00005598a5aac000)

Die Lösung bestand darin, das Paket mod_wsgi zu entfernen und das Paket rh-python36-mod_wsgi zu installieren.

Freundliche Grüße!

0
Bstia