2008-11-19 12 views
9

Estoy tratando de ejecutar mis sitios de Django con mod_wsgi en lugar de mod_python (RHEL 5). Intenté esto con todos mis sitios, pero tengo el mismo problema. Lo configuré de la manera estándar que todo el mundo recomienda, pero las solicitudes al sitio simplemente exceden el tiempo de espera.Ejecutando un sitio de Django en mod_wsgi

Apache conf:

<VirtualHost 74.54.144.34> 
    DocumentRoot /wwwclients/thymeandagain 
    ServerName thymeandagain4corners.com 
    ServerAlias www.thymeandagain4corners.com 
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined 
    CustomLog /var/log/httpd/thymeandagain_access_log combined 
    ErrorLog /var/log/httpd/thymeandagain_error_log 
    LogLevel error 
    WSGIScriptAlias//wwwclients/thymeandagain/wsgi_handler.py 
    WSGIDaemonProcess thymeandagain user=admin group=admin processes=1 threads=16 
    WSGIProcessGroup thymeandagain 
</VirtualHost> 

wsgi_handler.py:

import sys 
import os 

sys.path.append("/wwwclients") 
os.environ['DJANGO_SETTINGS_MODULE'] = 'thymeandagain.settings' 

import django.core.handlers.wsgi 

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

El mod_wsgi demonio se supone para desovar fuera no está allí, por lo que las solicitudes acaba el tiempo de espera y me da un montón de "No se puede para conectarse a los errores del proceso demoníaco WSGI en los registros. ¿Hay algo sobre la directiva WSGIDaemonProcess que impida la creación del daemon? Gracias de antemano por cualquier ayuda ...

EDIT: me sale esto en el registro de errores:

[[email protected]] mcm_server_readable():2582: timeout: Operation now in progress: select(2) call timed out for read(2)able fds 
[[email protected]] mcm_get_line():1592 
[[email protected]] mcm_server_readable():2582: timeout: Operation now in progress: select(2) call timed out for read(2)able fds 
[[email protected]] mcm_get_line():1592 
[Thu Nov 20 21:18:17 2008] [notice] caught SIGTERM, shutting down 
[Thu Nov 20 21:18:18 2008] [notice] Digest: generating secret for digest authentication ... 
[Thu Nov 20 21:18:18 2008] [notice] Digest: done 
[Thu Nov 20 21:18:18 2008] [notice] mod_python: Creating 4 session mutexes based on 8 max processes and 64 max threads. 
[Thu Nov 20 21:18:18 2008] [notice] Apache/2.2.3 (Red Hat) mod_python/3.2.8 Python/2.4.3 mod_wsgi/2.1-BRANCH configured -- resuming normal operations 
+0

¿Hay algo en el registro de errores del servidor? Creo que te diría allí si hubo un problema al iniciar el proceso demonio de WSGI. – Powerlord

+0

Esto resolvió mi problema http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html –

Respuesta

4

El problema es que mod_python no va bien junto con mod_wsgi. Me metí en un problema similar hace unas semanas y todo comenzó a funcionar para mí poco después de que comencé la inclusión de mod_python.

intentar buscar modwsgi.org wiki para "mod_python", creo que había alguien hablando de esto en alguna parte en los comentarios

1

Here es descripción muy detallada sobre cómo integrar Django con mod_wsgi.

10

El problema real es permisos de directorio de registro de Apache. Es necesario indicarle a Apache/mod_wsgi que use una ubicación alternativa para los sockets de UNIX utilizados para comunicarse con los procesos de daemon. Ver:

http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of_UNIX_Sockets

+0

Este fue mi problema exactamente; ejecutando CentOS 6 con stock-httpd.conf en su mayoría, no he cargado mod_python (como se sugirió otra respuesta), ¡pero la configuración de WSGISocketPrefix y los permisos apropiados en el directorio de sockets lo arreglaron! – mjjohnson

+1

Este fue mi problema también. Estoy ejecutando en RHEL6 y agregando 'WSGISocketPrefix/var/run/wsgi' al httpd.conf solucionado. – Nifle

Cuestiones relacionadas