2010-01-21 18 views
13

Estoy trabajando con mi proveedor de alojamiento para poner en marcha una aplicación Django, pero ninguno de nosotros tiene mucha experiencia y básicamente hemos llegado a un callejón sin salida.No se puede resolver la excepción mod_wsgi en la configuración de Django

no tengo acceso directo al archivo de configuración, pero así es como sus contenidos se han descrito a mí:

<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/ 

Mi "django.wsgi" guión es nada del otro mundo:

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

Por lo tanto, tengo entendido que todo esto significa que si se recibe una solicitud para domain.com/fredapp/, se debe entregar a la aplicación a través de django.wsgi. Sin embargo, la única respuesta que recibo es:

[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 

Esto se ejecuta con Apache en Linux. He intentado ejecutar cada línea del script .wsgi en el intérprete de Python en el servidor, y ninguno de ellos devuelve ningún error. También probé el truco sys.stdout = sys.stderr y no obtuve más resultados que los anteriores. El archivo no existe. Los errores tienen que ver con el resto de la configuración del sitio y ocurren en cualquier solicitud. No he terminado de configurar todo correctamente (páginas de error y páginas de índice, etc.) porque solo intento que la aplicación se ejecute.

He instalado esta aplicación en Apache en mi máquina, aunque NO en modo Daemon, pero es mi primera aplicación Django, y no creo que mi proveedor de alojamiento haya configurado alguna antes, así que está volando un poco a ciegas. Si alguien tiene alguna sugerencia, estaría muy agradecido. ¡Gracias!

+1

Debe haber un rastreo u otros mensajes después de que se haya producido una 'Excepción al procesar la secuencia de comandos de WSGI' en el archivo de registro de errores de Apache. ¿Qué son? –

Respuesta

1

¿Es posible que su directorio inicial no sea el único en el que se encuentra el proyecto?

Hoy también fue la creación de Apache + mod_wsgi + Django aplicación y después de agregar a django.wsgi:

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

todo comenzó a trabajar como un encanto.

+0

Gracias por la sugerencia - Lo intenté, pero no funcionó. Aún obteniendo la misma excepción. – barsoomcore

+2

Es una mala práctica depender del directorio de trabajo actual para las aplicaciones web porque no puede garantizar lo que puede ser bajo diferentes soluciones de alojamiento. Cambiar el directorio de trabajo como usted no necesariamente funcionará, ya que técnicamente podría tener otras aplicaciones ejecutándose en el mismo proceso que hagan lo mismo y usted puede arruinarlas o lo arruinarán. Por lo tanto, siempre use nombres de ruta absolutos y asegúrese de establecer correctamente la ruta de búsqueda del módulo de Python en lugar de depender de las importaciones relativas al directorio de trabajo actual. –

+0

@Graham Dumpleton: me doy cuenta de que esta es una mala práctica, pero tengo un código que crea algunos archivos de registro en el directorio actual. Es para ser refactorizado, pero por un tiempo tengo que vivir con este truco. –

0

Tuvimos el mismo error cuando el usuario que ejecutaba Apache no tenía los derechos para leer los archivos.

+1

¿Y qué? ¿Que pasó? ¿Cuál fue la resolución? Si te gusta la pregunta, recíbela. Esta no es una respuesta. –

+0

@ S.Lott: bueno, es una especie de respuesta, ya que los usuarios cómo quieren verificar si pueden solucionar el problema configurando los derechos de archivo correctos pueden buscar el comando específico del SO en google ... Sé que la respuesta puede dar una mucha más información, pero no diría que no es una respuesta ... –

16

Si la configuración citada es la que está utilizando, el error es bastante obvio en realidad. Tiene:

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

que debe ser:

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

Es decir, el nombre del grupo de proceso debe coincidir.

Usted embargo debe haber visto un mensaje de error:

No WSGI daemon process called 'scratchf' has been configured 

Ésta sería probablemente antes de que el error registrado:

Exception occurred processing WSGI script 

Es por esto que es importante proveer todos los mensajes de registro de errores y no asuma que no son relevantes.

Como alternativa, tiene una configuración de cita diferente a la que está utilizando o no toda la configuración.


ACTUALIZA 1

Parece que es posible que tenga ErrorDocument permitido en Apache para redireccionar los errores a una URL específica. Sin embargo, si ha montado Django en el servidor web y no ha excluido el envío de dichas URL a Django, cuando se genera un error, Django recibe la redirección del documento de error pero no puede resolver la URL y genera un 404. Como Apache vio un 404 para redirigir la página de error, devuelve una página de error predeterminada de 500. El resultado final es que se pierde el verdadero error original y cualquier información.

Por lo tanto, vaya a la configuración de Apache y comente las directivas ErrorDocument.


ACTUALIZACIÓN 2

cambio de configuración en:

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

Usted no debería tener una barra final en el segundo valor en la línea. Perdió que en realidad estaba tratando de montar en la URL secundaria y no en la raíz del servidor web.

+0

Mi error al transcribir, lo siento. Los nombres de proceso y grupo de procesos coinciden; he actualizado la cita de configuración para reflejar eso. Sin embargo, es posible que esta cita de la configuración esté incompleta; como mencioné, no tengo acceso al archivo real, así que no puedo verificar esta información. Agregaré todos los resultados del registro de errores también. – barsoomcore

+0

Gracias. ¿Puedes aclarar a qué te refieres con "haber montado Django en la raíz del servidor web"? Mi raíz del servidor web es domain.com/, mientras que la aplicación Django está montada en domain.com/fredapp/. Es muy probable que sea un malentendido, sin embargo, si puede ser más claro aquí, lo agradecería. Verificaré con mi proveedor las directivas ErrorDocument de wrt. Gracias por el aporte. – barsoomcore

+0

Bueno, mi proveedor insiste en que no hay directivas ErrorDocument. En este punto, creo que buscaré un nuevo proveedor para esta aplicación. – barsoomcore

Cuestiones relacionadas