Exécution d'un site Django sous mod_wsgi

J'essaye d'exécuter mes sites Django avec mod_wsgi au lieu de mod_python (RHEL 5). J'ai essayé ceci avec tous mes emplacements, mais obtiens le même problème. Je l'ai configuré de la manière standard que tout le monde recommande, mais demande simplement au site d'expirer.Exécution d'un site Django sous 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()

Le démon mod_wsgi est censé se reproduire au large est pas là, en fait la demande juste le temps et je reçois un tas de « Impossible pour se connecter au processus démon WSGI "dans les journaux. La directive WSGIDaemonProcess empêche-t-elle la création du démon? Merci d'avance pour toute aide ...

EDIT: Je reçois cela dans le journal des erreurs:

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

Source

2008-11-19 Gabriel Ross

Y at-il quelque chose dans le journal des erreurs du serveur? Je pense que cela vous dirait s'il y avait un problème lors du démarrage du démon WSGI. – Powerlord

Cela a résolu mon problème http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html –

Le problème est que mod_python ne va pas bien avec mod_wsgi. J'ai eu un problème similaire il y a quelques semaines et tout a commencé à fonctionner pour moi peu de temps après avoir commenté l'inclusion de mod_python.

Essayez de chercher modwsgi.org wiki pour « mod_python », je crois qu'il y avait quelqu'un parler de cela quelque part dans les commentaires

Source

2008-12-04 02:42:14 vvarp

Here est très description détaillée sur la façon d'intégrer django avec mod_wsgi.

Source

2008-11-19 18:21:34

Le vrai problème est des autorisations sur le répertoire du journal Apache. Il est nécessaire d'indiquer à Apache/mod_wsgi d'utiliser un autre emplacement pour les sockets UNIX utilisées pour communiquer avec les processus du démon. Voir:

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

Source

2009-06-24 12:35:32

C'était mon problème exactement; en cours d'exécution CentOS 6 avec httpd.conf principalement stock, je n'ai pas eu mod_python chargé (comme une autre réponse suggérée), mais la configuration de WSGISocketPrefix et les autorisations appropriées sur le répertoire de socket l'ont corrigé! – mjjohnson

C'était mon problème aussi. Je cours sur RHEL6 et l'ajout de 'WSGISocketPrefix/var/run/wsgi' au fichier httpd.conf l'a corrigé. – Nifle

Exécution d'un site Django sous mod_wsgi

Répondre

Questions connexes