2010-01-21 3 views
13

Ich arbeite mit meinem Hosting-Provider, um eine Django-Anwendung zum Laufen zu bringen, aber keiner von uns ist sehr erfahren und wir haben im Grunde genommen eine totale Sackgasse erreicht.Kann mod_wsgi Ausnahme in Django-Setup nicht lösen

Ich habe keinen direkten Zugriff auf die conf-Datei, aber hier ist, wie sein Inhalt mir beschrieben wurden:

<IfModule mod_wsgi.c> 
WSGIScriptAlias /fredapp/ /home/fred/public_html/cgi-bin/fredapp/apache/django.wsgi 
WSGIDaemonProcess fred threads=15 display-name=%{GROUP} python-path=/home/fred/public_html/cgi-bin/fredapp/apache/ 
WSGIProcessGroup fred 
WSGIApplicationGroup %{GLOBAL} 
</IfModule> 

Alias /robots.txt /home/fred/public_html/fred-site/robots.txt 
Alias /favicon.ico /home/fred/public_html/fred-site/favicon.ico 

Alias /settings/media/ /home/fred/public_html/fred-site/media/ 

Mein „django.wsgi“ Skript ist nichts Besonderes:

import os, sys 
sys.path.append('/home/fred/public_html/cgi-bin/') 
sys.path.append('/home/fred/public_html/cgi-bin/fredapp/') 
os.environ['DJANGO_SETTINGS_MODULE'] = 'fredapp.settings' 

import django.core.handlers.wsgi 

application = django.core.handlers.wsgi.WSGIHandler() 

Also mein Verständnis ist, dass dies bedeutet, dass, wenn eine Anfrage für domain.com/freedapp/ kommt, dass es über django.wsgi an die Anwendung übergeben werden soll. Die einzige Antwort, die ich bekomme, ist jedoch:

[Fri Jan 22 18:46:08 2010] [error] [client xx.xxx.xx.xx] File does not exist: /home/fred/public_html/domain.com/500.shtml 
[Fri Jan 22 18:46:08 2010] [error] [client xx.xxx.xx.xx] mod_wsgi (pid=26760): Exception occurred processing WSGI script '/home/fred/public_html/cgi-bin/fredapp/apache/django.wsgi'. 
[Fri Jan 22 18:46:03 2010] [error] [client xx.xxx.xx.xx] File does not exist: /home/fred/public_html/domain.com/404.shtml 
[Fri Jan 22 18:46:03 2010] [error] [client xx.xxx.xx.xx] File does not exist: /home/fred/public_html/domain 

Dies läuft unter Apache unter Linux. Ich habe versucht, jede Zeile des .wsgi-Skripts im Python-Interpreter auf dem Server auszuführen, und keiner von ihnen gibt irgendwelche Fehler zurück. Ich habe auch versucht, die sys.stdout = sys.stderr Trick und bekam keine weitere Ausgabe als das, was oben ist. Die Datei existiert nicht, Fehler haben mit dem Rest der Site-Einrichtung zu tun und treten bei jeder Anfrage auf. Ich habe noch nicht alles richtig eingerichtet (Fehlerseiten und Indexseiten usw.), weil ich nur versuche, die App selbst zum Laufen zu bringen.

Ich habe diese App unter Apache auf meinem eigenen Rechner laufen lassen, allerdings NICHT im Daemon-Modus, aber es ist meine erste Django-App, und ich glaube nicht, dass mein Hosting-Provider jemals zuvor einen konfiguriert hat flieg ein bisschen blind. Wenn jemand irgendwelche Vorschläge hat, wäre ich sehr dankbar. Vielen Dank!

+1

Es sollte eine Rückverfolgung oder andere Nachrichten geben, nachdem 'Ausnahme bei der Verarbeitung des WSGI-Skripts aufgetreten ist' in der Apache-Fehlerprotokolldatei. Was sind Sie? –

Antwort

1

Ist es möglich, dass Ihr Startverzeichnis nicht das eine Projekt ist?

Heute habe ich auch + mod_wsgi + Django app Apache wurde, Einstellung und nach django.wsgi zum Hinzufügen:

os.chdir('/home/user/my_django_project') 

alles begann wie ein Zauber zu arbeiten.

+0

Danke für den Vorschlag - Ich habe es versucht, aber es hat nicht funktioniert. Immer noch die gleiche Ausnahme. – barsoomcore

+2

Es ist eine schlechte Praxis, sich auf das aktuelle Arbeitsverzeichnis für Webanwendungen zu verlassen, da Sie nicht garantieren können, was es unter verschiedenen Hosting-Lösungen gibt. Das Ändern des Arbeitsverzeichnisses, wie Sie es haben, wird nicht unbedingt funktionieren, da Sie technisch gesehen andere Anwendungen im selben Prozess ausführen könnten, die dasselbe tun und Sie können sie vermasseln oder sie werden Sie vermasseln. Verwenden Sie daher immer absolute Pfadnamen und stellen Sie sicher, dass Sie den Python-Modul-Suchpfad korrekt festlegen, anstatt sich auf Importe im Vergleich zum aktuellen Arbeitsverzeichnis zu verlassen. –

+0

@Graham Dumpleton: Ich weiß, das ist schlechte Praxis, aber ich habe einige Code, der einige Protokolldateien im aktuellen Verzeichnis erstellt. Es ist umzustrukturiert, aber für eine Weile muss ich mit diesem Hack leben. –

0

Wir hatten den gleichen Fehler, wenn der Benutzer mit Apache nicht über die Rechte zum Lesen der Dateien verfügte.

+1

Und was? Was ist passiert? Was war die Lösung? Wenn Sie die Frage mögen, upvote es. Dies ist keine Antwort. –

+0

@ S.Lott: Nun, es ist eine Art von Antwort wie Benutzer überprüfen möchten, ob sie das Problem beheben können, indem Sie die richtigen Dateirechte können den OS-spezifischen Befehl auf Google suchen ... Ich weiß, die Antwort kann geben viel mehr Infos, aber ich würde nicht sagen, dass es keine Antwort ist ... –

16

Wenn die angegebene Konfiguration über das ist, was Sie verwenden, ist der Fehler tatsächlich ziemlich offensichtlich. Sie haben:

WSGIDaemonProcess fred threads=15 display-name=%{GROUP} python-path=/home/fred/public_html/cgi-bin/fredapp/apache/ 
WSGIProcessGroup scratchf 

Es sollte:

WSGIDaemonProcess fred threads=15 display-name=%{GROUP} python-path=/home/fred/public_html/cgi-bin/fredapp/apache/ 
WSGIProcessGroup fred 

Das heißt, muss der Name der Prozessgruppe entsprechen.

Sie allerdings eine Fehlermeldung gesehen haben sollte:

No WSGI daemon process called 'scratchf' has been configured 

Dies vor dem angemeldeten Fehler wahrscheinlich wäre:

Exception occurred processing WSGI script 

Aus diesem Grund ist es wichtig, dass Sie alle Fehlerprotokollmeldungen liefern und nicht davon ausgehen, dass sie nicht relevant sind.

Alternativ haben Sie eine andere als die von Ihnen verwendete Konfigurationskonfiguration angegeben.


UPDATE 1

Es sieht aus wie Sie Errordocument in Apache aktiviert haben können Fehler auf eine bestimmte URL zu umleiten. Da Sie jedoch Django im Stammverzeichnis des Webservers installiert haben und nicht ausgeschlossen haben, dass diese Fehler-URLs an Django weitergegeben werden, erhält Django beim Auftreten eines Fehlers die Umleitung für das Fehlerdokument, kann jedoch die URL nicht auflösen und generiert anschließend eine 404. Da Apache 404 eine Fehlerseitenumleitung sah, wird eine 500-Standardfehlerseite zurückgegeben. Das Endergebnis ist, dass der ursprüngliche Originalfehler und jegliche Informationen verloren gehen.

Gehen Sie also in die Apache-Konfiguration und kommentieren Sie die ErrorDocument-Anweisungen aus.


UPDATE 2

Konfiguration ändern zu:

WSGIScriptAlias /fredapp /home/fred/public_html/cgi-bin/fredapp/apache/django.wsgi 

Sie sollten nicht haben Strich auf dem zweiten Wert auf der Leitung nachlauf. Sie haben vergessen, dass Sie tatsächlich versucht haben, eine Unter-URL und nicht die Root-Seite des Webservers bereitzustellen.

+0

Mein Fehler beim Transkribieren, sorry. Die Prozess- und Prozessgruppennamen stimmen überein - ich habe das Konfigurationsangebot aktualisiert, um dies zu berücksichtigen. Es ist sicherlich möglich, dass dieses Zitat der Konfiguration unvollständig ist. Wie gesagt, ich habe keinen Zugriff auf die eigentliche Datei, so dass ich diese Informationen nicht überprüfen kann. Ich werde auch alle Ausgaben des Fehlerprotokolls hinzufügen. – barsoomcore

+0

Danke. Kannst du klarstellen, was du unter "habe Django an der Wurzel des Webservers gemountet" verstanden hast? Mein Webserver-Root ist domain.com/, während die Django-App unter domain.com/freppapp installiert ist. Es ist sehr wahrscheinlich, dass ich Missverständnisse, aber wenn Sie hier klarer sein können, würde ich es begrüßen. Ich werde mit meinem Provider in ErrorDocument-Anweisungen überprüfen. Danke für die Eingabe. – barsoomcore

+0

Nun, mein Provider besteht darauf, dass es keine ErrorDocument-Anweisungen gibt. An dieser Stelle denke ich, dass ich einen neuen Anbieter für diese App suchen werde. – barsoomcore

Verwandte Themen