Ich versuche, django App mit mod_wsgi auf CentOS 5

Question

arbeiten Ich bin CentOS 5 laufen, und versuche, eine Django-Anwendung mit mod_wsgi arbeiten. Ich benutze .wsgi Einstellungen Ich habe an Ubuntu gearbeitet. Ich bin auch eine alternative Installation von Python (/opt/python2.6/), da meine django-Anwendung benötigt> 2.5 und das OS verwendet 2.3

Hier ist die Fehlermeldung:

[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] SystemError: dynamic module not initialized properly 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] mod_wsgi (pid=23630): Target WSGI script '/data/hosting/cubedev/apache/django.wsgi' cannot be loaded as Python module. 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] mod_wsgi (pid=23630): Exception occurred processing WSGI script '/data/hosting/cubedev/apache/django.wsgi'. 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] Traceback (most recent call last): 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] File "/data/hosting/cubedev/apache/django.wsgi", line 8, in 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] import django.core.handlers.wsgi 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] File "/opt/python2.6/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 1, in 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] from threading import Lock 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] File "/opt/python2.6/lib/python2.6/threading.py", line 13, in 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] from functools import wraps 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] File "/opt/python2.6/lib/python2.6/functools.py", line 10, in 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] from _functools import partial, reduce 
[Thu Mar 04 10:52:15 2010] [error] [client 10.1.0.251] SystemError: dynamic module not initialized properly 

Und hier ist meine .wsgi Datei

import os 
import sys 
os.environ['PYTHON_EGG_CACHE'] = '/tmp/django/' # This line was added for CentOS. 
os.environ['DJANGO_SETTINGS_MODULE'] = 'cube.settings' 

sys.path.append('/data/hosting/cubedev') 

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

Ausgabe von ldd /usr/lib/httpd/modules/mod_wsgi.so

linux-gate.so.1 => (0x00250000) 
libpython2.6.so.1.0 => /opt/python2.6/lib/libpython2.6.so.1.0 (0x00be6000) 
libpthread.so.0 => /lib/libpthread.so.0 (0x00110000) 
libdl.so.2 => /lib/libdl.so.2 (0x00557000) 
libutil.so.1 => /lib/libutil.so.1 (0x00128000) 
libm.so.6 => /lib/libm.so.6 (0x0012c000) 
libc.so.6 => /lib/libc.so.6 (0x00251000) 
/lib/ld-linux.so.2 (0x0039a000) 

vHost Konfi g

<VirtualHost *:80> 
    ServerAdmin admin@example.com 
    ServerAlias cube-dev.example.com 
    ServerName cube-dev.example.com 
    ErrorLog logs/cube-dev.example.com.error_log 
    CustomLog logs/cube-dev.example.com.access_log common 
    Alias /phpMyAdmin /var/www/phpMyAdmin/ 
    # DocumentRoot /data/hosting/cubedev 

    WSGIScriptAlias//data/hosting/cubedev/apache/django.wsgi 

    WSGIProcessGroup cubedev.example.com 
    WSGIDaemonProcess cubedev.example.com 

    Alias /media/ /data/hosting/cubedev/media/ 
    Alias /adminmedia/ /opt/python2.6/lib/python2.6/site-packages/django/contrib/admin/media/ 
    Alias /media /data/hosting/cubedev/media 

    <Directory "/data/hosting/cubedev/media"> 
    Order deny,allow 
    Allow from all 
    </Directory> 
</VirtualHost> 

Answer 1

SystemError: dynamic module not initialized properly ist die Ausnahme, die ausgelöst wird, wenn eine DLL (oder .so), die geladen werden, richtig initialisiert nicht wird. In Funktion _PyImport_LoadDynamicModule von Python/importdl.c falls jemand interessiert ist.

Nun wird die DLL/so in Frage (das dynamische Modul in Python parliance) ist, der Teil _functools.so Python Standard-Bibliothek ist. Ich sehe, dass es von /opt/python2.6 geladen wird, damit wir wissen, dass dies nicht das System Python ist. Meine Vermutung ist, dass dies nicht der Python ist, gegen den mod_wsgi kompiliert wurde. Um zu überprüfen, ob dies der Fall ist, führen Sie ldd mod_wsgi.so aus und schauen Sie sich an, was libpython zurückgegeben wird.

Deshalb mein Vorschlag ist entweder neu kompilieren mod_wsgi againast der Dolmetscher in /opt/python2.6 von im wsgi_mod Quellverzeichnis ausgeführt

./configure --with-python=/opt/python2.6/bin/python2.6 

oder sicherstellen, dass sys.prefix verweist auf die Python-Installation, die mod_wsgi erwartet von Setzen Sie seinen Wert mit dem Verzeichnis WSGIPythonHome.

UPDATE nach LDD Ausgang

Die zweite Zeile in der LDD-Ausgabe zeigt, dass die mod_wsgi pythonlib in /usr/lib anstelle von /opt/python2.6 lädt. Um mod_wsgi anzuweisen, das in zu laden, sollten Sie es wahrscheinlich der Umgebungsvariablen LD_LIBRARY_PATH voranstellen.

es zuerst auf der Kommandozeile Versuche:

LD_LIBRARY_PATH=/opt/python2.6/lib:$LD_LIBRARY_PATH ldd mod_wsgi.so 

und vergewissern Sie sich, dass die richtige LD_LIBRARY_PATH im Skript angegeben wird, die Apache startet.

Noch ein weiteres Update

Sie werden Ihre mod_wsgi Konfiguration debuggen müssen. Versuchen Sie einfach mit der folgenden .wsgi Datei anstelle von Ihnen und uns sagen, was Sie bekommen:

def application(environ, start_response): 
    status = '200 OK' 
    start_response(status, [('Content-type', 'text/plain')]) 

    try: 
     import sys 
     return ['\n'.join([sys.prefix, sys.executable])] 
    except: 
     import traceback as tb 
     return [tb.format_exc()] 

Wenn das, was man bekommt, ist nicht `/ opt/python2.6' , versuchen Sie mit der Option

WSGIPythonHome /opt/python2.6 

Siehe auch http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives