2014-11-09 10 views
6

Es ist üblich, dass Leute Schwierigkeiten haben, django einzurichten, um von Apache und mod-wsgi bedient zu werden. Das übliche Symptom ist "Importfehler" ... aus irgendeinem Grund (in der Regel jeweils etwas anders) wird settings.py oder ähnliches nicht importiert (siehe "Verwandte" in der rechten Spalte auf dieser Seite für zahlreiche Beispiele!).Wie Debuggen grundlegende Probleme beim Konfigurieren von Django mit Apache und Mod-Wsgi serviert werden?

Ich habe die anderen Fragen zu diesem Thema durchgelesen, und keine scheint eine Lösung zu haben, die für meine Situation funktioniert (eine war eine grundlegende Misconfig durch das Poster von einem Beantworter identifiziert - ich habe dieses Problem anscheinend nicht , andere gelten für die Verwendung von wsgi aus anderen Modulen usw.).

Wenn Apache/Mod-Wsgi nicht geladen werden kann, wie können Sie es debuggen?

Was können Sie tun, damit etwas eine bessere Nachricht als "Import error" gibt?

Offensichtlich bin ich auf der Suche nach einer Methode, die identifizieren wird, was in meinem Fall falsch ist. Aber ich würde wirklich gerne wissen, wie man sich mit der Fehlersuche befasst: Es scheint unmöglich zu sein, Informationen darüber zu finden, was es zum Scheitern bringt.


In meinem Fall, ich versuche zu tun, was ein straightforwards django zu sein scheint mit mod-wsgi einsetzen - wirklich durch das Buch, das gleiche wie die doc, aber den Fehler:

ImportError: Could not import settings 'cm_central.settings' (Is it on sys.path? Is there an import error in the settings file?): No module named cm_central.settings 

Ich kann nicht sehen, warum es dieses Modul nicht finden kann.

/home/cmc/src/cm_central/cm_central/settings.spy existiert, kann von Python ohne Fehler geladen werden und funktioniert in der Tat mit ./manage.py runserver OK.

Ist es möglich, dass im Zusammenhang mit Apache ein Importfehler auftritt, der nicht auftritt, wenn ich ihn selbst lade? Ich wundere mich wegen der Worte "Gibt es einen Importfehler in der Einstellungsdatei?" ... warum fragt es das? Wenn es einen Importfehler gab, wie würde ich es debuggen?

Ich habe dies in/etc/apache2/sites-enabled/cm-Mittel:

<VirtualHost *:80> 

    WSGIScriptAlias//home/cmc/src/cm_central/cm_central/wsgi.py 
    WSGIDaemonProcess cm-central.johalla.de python-path=/home/cmc/src/cm_central:/home/cmc/virtualenvs/cmc/lib/python2.7/site-packages 
    WSGIProcessGroup cm-central.johalla.de 

    <Directory /home/cmc/src/cm_central/cm_central> 
    <Files wsgi.py> 
     Order deny,allow 
     Allow from all 
    </Files> 
    </Directory> 

</VirtualHost> 

Und das in wsgi.py: (es habe ich geändert es nicht von dem, was django generiert)

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

from django.core.wsgi import get_wsgi_application 
from dj_static import Cling 

application = Cling(get_wsgi_application()) 

Die vollständige Rückverfolgung ist:

[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] mod_wsgi (pid=10273): Target WSGI script '/home/cmc/src/cm_central/cm_central/wsgi.py' cannot be loaded as Python module. 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] mod_wsgi (pid=10273): Exception occurred processing WSGI script '/home/cmc/src/cm_central/cm_central/wsgi.py'. 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] Traceback (most recent call last): 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] File "/home/cmc/src/cm_central/cm_central/wsgi.py", line 16, in <module> 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40]  application = Cling(get_wsgi_application()) 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] File "/home/cmc/virtualenvs/cmc/lib/python2.7/site-packages/django/core/wsgi.py", line 14, in get_wsgi_application 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40]  django.setup() 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] File "/home/cmc/virtualenvs/cmc/lib/python2.7/site-packages/django/__init__.py", line 20, in setup 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40]  configure_logging(settings.LOGGING_CONFIG, settings.LOGGING) 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] File "/home/cmc/virtualenvs/cmc/lib/python2.7/site-packages/django/conf/__init__.py", line 46, in __getattr__ 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40]  self._setup(name) 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] File "/home/cmc/virtualenvs/cmc/lib/python2.7/site-packages/django/conf/__init__.py", line 42, in _setup 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40]  self._wrapped = Settings(settings_module) 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] File "/home/cmc/virtualenvs/cmc/lib/python2.7/site-packages/django/conf/__init__.py", line 98, in __init__ 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40]  % (self.SETTINGS_MODULE, e) 
[Sun Nov 09 12:00:01 2014] [error] [client 192.168.122.40] ImportError: Could not import settings 'cm_central.settings' (Is it on sys.path? Is there an import error in the settings file?): No module named cm_central.settings 
[Sun Nov 09 12:04:06 2014] [notice] Graceful restart requested, doing restart 
[Sun Nov 09 12:04:06 2014] [notice] Apache/2.2.22 (Debian) PHP/5.4.4-14+deb7u14 mod_wsgi/3.3 Python/2.7.3 configured -- resuming normal operations 
[Sun Nov 09 21:34:15 2014] [error] Not Found:/

Wenn eine Antwort mir helfen könnte zu erkennen, was falsch ist, das wäre toll - aber noch besser ist ein n Antwort auf "wie man das debuggt". Wie findet man heraus warum die settings.py wird nicht geladen?

Antwort

1

Endlich ein answer to the high level question: how to debug?

Und es ist so offensichtlich:

Ausdruck alles, was von settings.py zählt, und suchen Sie in der Apache-Protokoll Sieh, was du hast, vergleiche es mit dem, was du in Entwicklung bekommst!

Der verlinkte Artikel dieser Reihe von Abzügen in settings.py schlägt vor:

import sys, os

print "__name__ =", __name__ 
print "__file__ =", __file__ 
print "os.getpid() =", os.getpid() 
print "os.getcwd() =", os.getcwd() 
print "os.curdir =", os.curdir 
print "sys.path =", repr(sys.path) 
print "sys.modules.keys() =", repr(sys.modules.keys()) 
print "sys.modules.has_key('mysite') =", sys.modules.has_key('mysite') 
if sys.modules.has_key('mysite'): 
    print "sys.modules['mysite'].__name__ =", sys.modules['mysite'].__name__ 
    print "sys.modules['mysite'].__file__ =", sys.modules['mysite'].__file__ 
    print "os.environ['DJANGO_SETTINGS_MODULE'] =", os.environ.get('DJANGO_SETTINGS_MODULE', None) 

Für meine Zwecke habe ich auch noch DATABASE_URL und später EMAIL_HOST_USER etc

Die Artikel hat auch eine gute Erklärung, wie der gesamte Startvorgang passiert, was sich lohnt.

Beachten Sie, dass es mit dem Django selbst ein wenig veraltet ist, so dass die endgültige "Alternative wsgi.py", auf die er kommt, möglicherweise nicht so anwendbar ist, aber die Debugging-Technik ist sicherlich.

+0

Danke für alle Kommentare, die darauf hindeuten, was mein spezifisches Problem sein könnte - sie waren auch hilfreich. – GreenAsJade

0

Können Sie versuchen, eine leere __init__.py Datei im Verzeichnis cm_central hinzuzufügen? Abhängig davon, wie die Einstellungen importiert werden, wäre dies erforderlich.

+0

Django bietet eine von diesen - es ist vorhanden. – GreenAsJade

+0

Beachten Sie, dass diese "Antwort" einen Vorschlag darüber enthält, was in meinem Fall falsch sein könnte (was ich wirklich schätze), aber nicht die Frage "Wie debütiert man solche Probleme?" Beantwortet. Es scheint wirklich, dass Versuch und Irrtum der einzige Weg ist, um wsgi Ladeprobleme zu lösen, die ... suboptimal scheint? – GreenAsJade

1

Es könnte ganz andere Gründe für Ihr Problem geben.

Berechtigungen - vielleicht läuft Ihr wsgi-Daemon-Prozess unter einem anderen Benutzer/einer anderen Gruppe als wenn Sie interaktiv mit python manage.py runserver versuchen. Vielleicht machen die Berechtigungen, die für Ihre Dateien festgelegt sind, einen Unterschied.versuche vielleicht, den gleichen Benutzer wie für den Daemon interaktiv zu verwenden oder umgekehrt. mod_wsgi hat schöne Optionen, damit Sie Ihre Daemons unter separaten Benutzern ausführen können, was auch aufgrund der Trennung für die Sicherheit gut ist.

sys.path könnte anders sein (obwohl es in Ihrer Daemon-Konfiguration irgendwie korrekt aussieht), könnte die cwd anders sein.

wie Sie scheinen eine virtualenv verwenden Sie vielleicht möchten auch die speziellen Installationsanweisungen für Mod-wsgi and Virtualenvs

+0

Ja - das sind alles mögliche Gründe und daher meine Frage "Wie kann ich die Situation debuggen?". Eine Möglichkeit ist, solche Dinge der Reihe nach zu betrachten und zu raten, ob sie richtig sind. Ich hoffe irgendwie auf etwas "deterministischeres" - eine Möglichkeit, eine Fehlermeldung von irgendwo zu bekommen, die mir sagt, was falsch ist ... eine andere Sache, die ich nicht erwähnte, ist die Konfiguration der Datenbank, und eine andere ist DOKUMENT ROOT. All diese Dinge könnten falsch sein: Wie kann ich Django oder Apache anlocken, um eine bessere Nachricht auszugeben, um sie zu debuggen? – GreenAsJade

+0

(Hinweis: die django docs hatten ein paar Tipps zu virtualenv, aber ich muss auch die Seite überprüfen, die du verlinkt hast - Danke, tue) – GreenAsJade

1

folgen könnten Sie versuchen, diese wsgi.py zu Ihrer hinzufügen:

path = os.path.join(os.path.dirname(__file__), "..") # Adapt the path here to match the root of your django project 
if path not in sys.path: 
    sys.path.append(path) 

um sicherzustellen, dass Django Projekt im Python-Pfad?

If an answer could help me spot what's wrong, that'd be great - but even better is an answer to "how to debug this". How does one find out why the settings.py won't load?

Es ist schwer, diese Frage zu beantworten, wenn wir nicht genau wissen, was Sie bereits versucht haben. Basierend auf dem Rückverfolgungs (Is it on sys.path? Is there an import error in the settings file?), würde ich sagen:

  • Überprüfen Sie, ob Ihr django Projekt Basisordner in der Python-Pfad ist (was ich habe Sie noch nicht gelesen haben getan, deshalb habe ich den Vorschlag gemacht oben

    )
  • überprüfen, dass es keine Ausnahmen ausgelöst, wenn Ihre settings.py Datei zu laden (die Sie bereits haben)

+0

Danke für diese Vorschläge, ich werde sie versuchen. Nach was ich wirklich suche, obwohl (was die Frage verlangt) wir "wie bekomme ich eine bessere Fehlermeldung als, konnte settings.py nicht importieren?". Wie kann ich etwas sagen, warum es nicht importieren konnte? Wenn wir diese Frage beantworten könnten, wären viele ähnliche Fragen gelöst! – GreenAsJade

1

Zuerst auf die eigentliche Frage hier. Wie bekomme ich mehr Informationen darüber, was genau fehlschlägt? Ich könnte mich irren, aber ich bin mir fast sicher, dass es keine Tools/Pakete/Logs oder was auch immer gibt, die Ihnen mehr Informationen über das Problem geben würden als das, was Sie bereits haben: das Traceback. Also ich denke, der einzige Weg, um diese Fehler debuggen, ist das „Traceback“ -Methode ;-)

--- Nun zum Problem:

Vielleicht ist es ein Berechtigungsproblem. In Ihrem WSGIDaemonProcess geben Sie keinen Benutzer oder keine Gruppe an und vielleicht darf Apache die Dateien nicht lesen/ausführen. Können Sie versuchen, auf diese Zeile wie diese Benutzer und Gruppen hinzufügen:

WSGIDaemonProcess cm-central.johalla.de user=<username> group=<username> python-path=/home/cmc/src/cm_central:/home/cmc/virtualenvs/cmc/lib/python2.7/site-packages 

Auch sind Sie nicht ein DocumentRoot verwenden. Vielleicht ist es deshalb der richtige Weg? In meinem vhosts, schließe ich immer ein DocumentRoot, die den gleichen Weg wie das Verzeichnis, aber mit einem führenden Schrägstrich hat, in Ihrem Fall:

<VirtualHost *:80> 
    DocumentRoot /home/cmc/src/cm_central/cm_central/ 

Also vielleicht, dass Ihr Problem löst.

1

Die Fehlermeldung ist ziemlich explizite bereits - mod_wsgi kann nicht Ihre Einstellungsdatei (Linie 2, os.environ.setdefault) finden, Systempfad überprüfen (Ich verstehe, dass Django Ihre Einstellungsdatei finden kann, wenn Sie runserver verwenden, aber mod_wsgi nicht kann). Um Systempfad zu überprüfen, können Sie die wsgi.py File- und Print/log die sys.path ganz am Anfang der Datei ändern:

import sys 
print sys.path 

Zusätzlich zu den virtuellen env docs, auf den @Thomas Waldmann, können Sie auch Sie müssen das Projektverzeichnis manuell an den sys.path anhängen, wie erwähnt here in the Django config docs.Beispiel-Code ich verwende, ist unten:

ALLDIRS = ['/usr/local/pythonenv/assessments/lib/python2.6/site-packages'] 

import os 
import sys 
import site 

# from https://code.google.com/p/modwsgi/wiki/VirtualEnvironments 

sys.path.insert(0, '/var/www/assessments/assessments-main/') # settings.py file here 
sys.path.insert(1, '/var/www/assessments/') 

prev_sys_path = list(sys.path) 
for directory in ALLDIRS: 
    site.addsitedir(directory) 

new_sys_path = [] 
for item in list(sys.path): 
    if item not in prev_sys_path: 
     new_sys_path.append(item) 
     sys.path.remove(item) 

sys.path[:0] = new_sys_path 

os.environ['DJANGO_SETTINGS_MODULE'] = 'assessments-main.settings' 

import django.core.handlers.wsgi 
application = django.core.handlers.wsgi.WSGIHandler() 
+0

"Die Fehlermeldung ist schon ziemlich explizit - mod_wsgi kann Ihre Einstellungsdatei nicht finden" Ich bin mir nicht sicher. Beachten Sie, dass die Fehlermeldung fragt "Gibt es einen Fehler beim Importieren von settings.py?". Ich nehme das so an, dass es _ihr_ es nicht finden kann _or_ da ist etwas falsch darin! Ratgeber geben dieses Problem weiter, indem Sie überprüfen, ob Python die Einstellungsdatei importieren kann. Dies könnte entweder der Fall sein. Es war deutlicher, dass das Problem gerade darin besteht, dass es es nicht finden kann, es wäre hilfreicher. Bist du sicher, dass es nur darum geht, es zu finden? – GreenAsJade

+0

Tatsächlich sagt es nicht "kann nicht finden" es sagt "kann nicht importieren". Dies könnte daran liegen, dass sie nicht gefunden werden kann oder weil sie nicht eindeutig importiert werden kann. Das bedeutet, dass das Problem weit und breit sein kann: Berechtigungen für den Zugriff, Pfade in wsgi.py, oder irgendeine Anzahl von Gründen, warum Apache kann es nicht importieren, während Runserver kann. Daher die Notwendigkeit für eine Art zu debuggen, was schief geht :) – GreenAsJade

+0

Danke für den Zeiger auf IntegrationWithDjango, ich kann nicht glauben, dass ich das vorher nicht gesehen habe! – GreenAsJade

Verwandte Themen