2012-02-28 2 views
6

Когда я пытаюсь посетить сайт Django по адресу http://www.satoshi.example.com/mysite, я получаю 503 Service Temporary Unavailable.Django mod_wsgi apache

Журнал ошибок Apache говорит

[Tue Feb 28 07:11:09 2012] [error] [client 10.0.0.202] (13)Permission denied: mod_wsgi (pid=4756): Unable to connect to WSGI daemon process 'django' on '/etc/httpd/logs/wsgi.17555.4.1.sock' after multiple attempts. 

Apache правильно загружает mod_wsgi

[email protected]:~/html/mysite# apachectl -M | grep wsgi 
wsgi_module (shared) 
Syntax OK 

Apache загружает /var/www/html/mysite/apache/apache_django_wsgi.conf, который является

WSGIDaemonProcess django 
WSGIProcessGroup django 

<Directory "/var/www/html/mysite"> 
Order allow,deny 
Options Indexes 
Allow from all 
IndexOptions FancyIndexing 
</Directory> 

WSGIScriptAlias /mysite "/var/www/html/mysite/apache/django.wsgi" 

<Directory "/var/www/html/mysite/apache"> 
Order deny,allow 
Allow from all 
</Directory> 

Это /var/www/html/mysite/apache/django.wsgi

import os 
import sys 

paths = [ '/var/www/html/mysite', 
      '/usr/lib/python2.6/site-packages/', 
] 

for path in paths: 
    if path not in sys.path: 
     sys.path.append(path) 

os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' 

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

Одна странная вещь, что я узнал, что мне даже не нужно LoadModule wsgi_module modules/mod_wsgi.so самостоятельно httpd.conf. Я думаю, что мой httpd.conf является расширением другой конфигурации, которая уже загружена mod_wsgi. Не уверен, если это имеет значение.

Есть ли что-то не так с тем, что я представил до сих пор? Дайте мне знать, если вам нужна дополнительная информация. Заранее спасибо!

==================================================================================================================== =======

информация по просьбе @jpic

[email protected]:/var/www/html# ps aux | grep apache 
root  4564 0.0 0.2 207636 5432 pts/9 S+ 04:16 0:00 vi apache_django_wsgi.conf 
apache 6006 0.0 0.7 365140 14820 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6007 0.0 0.7 365140 14884 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6008 0.0 0.7 365140 14888 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6009 0.0 0.7 365140 14884 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6010 0.0 0.7 365008 14784 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6011 0.0 0.7 365008 14768 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6012 0.0 0.7 365008 14748 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6013 0.0 0.7 365140 14876 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6112 0.0 0.7 365008 14756 ?  S 10:05 0:00 /usr/sbin/httpd 
root  6116 0.0 0.2 207700 5492 pts/15 S+ 10:06 0:00 vi ../apache/django.wsgi 
apache 6181 0.0 1.5 713972 32136 ?  Sl 10:08 0:00 /usr/sbin/httpd 
root  8173 0.0 0.0 103300 848 pts/17 S+ 23:39 0:00 grep --color=auto apache 

информации пользователя (вы имели в виду id? userid не был найден)

[email protected]:/var/www/html# id apache 
uid=48(apache) gid=48(apache) groups=48(apache) 

ls -la информация

[email protected]:/var/www/html# ls -la /etc/ | grep httpd 
drwxrwxr-x. 4 root 4.0K Feb 16 18:27 httpd/ 

[email protected]:/var/www/html# ls -la /etc/httpd/ 
total 24K 
drwxrwxr-x. 4 root 4.0K Feb 16 18:27 ./ 
drwxr-xr-x. 128 root 12K Feb 28 03:45 ../ 
drwxr-xr-x. 2 root 4.0K Feb 28 08:07 conf/ 
drwxr-xr-x. 2 root 4.0K Feb 16 18:28 conf.d/ 
lrwxrwxrwx 1 root 19 Feb 16 18:27 logs -> ../../var/log/httpd/ 
lrwxrwxrwx 1 root 29 Feb 16 18:27 modules -> ../../usr/lib64/httpd/modules/ 
lrwxrwxrwx 1 root 19 Feb 16 18:27 run -> ../../var/run/httpd/ 

[email protected]:/var/www/html# ls -la /etc/httpd/logs/ 
total 528K 
drwxrwxr-x. 2 root 4.0K Feb 28 09:53 ./ 
drwxr-xr-x. 19 root 4.0K Feb 27 06:51 ../ 
-rw-r--r-- 1 root 17K Feb 28 10:08 access_log 
-rw-r--r-- 1 root 351 Feb 3 10:24 access_log-20120205 
-rw-r--r-- 1 root 1.8K Feb 7 01:39 access_log-20120212 
-rw-r--r-- 1 root 278K Feb 18 23:17 access_log-20120219 
-rw-r--r-- 1 root 85K Feb 22 08:38 access_log-20120226 
-rw-r--r-- 1 root 50K Feb 28 10:08 error_log 
-rw-r--r-- 1 root 14K Feb 5 03:28 error_log-20120205 
-rw-r--r-- 1 root 2.2K Feb 12 03:14 error_log-20120212 
-rw-r--r-- 1 root 9.4K Feb 19 03:28 error_log-20120219 
-rw-r--r-- 1 root 4.0K Feb 26 03:20 error_log-20120226 
-rw-r--r--. 1 root  0 Oct 14 15:14 ssl_access_log 
-rw-r--r-- 1 root 3.1K Feb 28 09:53 ssl_error_log 
-rw-r--r-- 1 root 1.4K Feb 3 03:25 ssl_error_log-20120205 
-rw-r--r-- 1 root 237 Feb 5 03:28 ssl_error_log-20120212 
-rw-r--r-- 1 root 1.2K Feb 17 01:52 ssl_error_log-20120219 
-rw-r--r-- 1 root 237 Feb 19 03:28 ssl_error_log-20120226 
-rw-r--r--. 1 root  0 Oct 14 15:14 ssl_request_log 
srw-rw-rw- 1 apache 0 Feb 28 09:53 wsgi.17555.14.1.sock 
+0

+1 для размещения журнала апачского. – jpic

ответ

9

Эта проблема описана в:

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

Решения, предоставляемые другими изменяющимися разрешений неверны.

Правильное решение - изменить, где файлы сокетов хранятся в месте, где пользователь Apache может их прочитать.

В системах, которые защищают каталог журналов, у них иногда есть система, позволяющая вернуть эти разрешения, когда вы с ними связываетесь. В результате любое изменение может быть только временным.

+0

мой опыт в том, что где бы вы ни установили местоположение сокета, они всегда будут иметь более строгие разрешения (например, srwx ------ www-data root), и поэтому вам нужно изменить разрешения сокетов. –

+1

Вам не нужно, и у вас нет возможности устанавливать разрешения сокета, потому что имя файла сокета динамически изменяется со временем на основе идентификатора процесса, генерации конфигурации Apache и экземпляра группы процессов демона. IOW, это не неизменное имя. Пока каталог доступен для пользователя Apache, все будет работать, так как mod_wsgi гарантирует, что фактические файлы сокетов имеют правильные разрешения. –

+1

@GrahamDumpleton Я изменил конфигурацию в соответствии с предоставленной вами ссылкой, но я все еще получаю сообщение об ошибке «Не удалось подключиться к процессу демонстрации WSGI« wsgi »на« /var/run/wsgi.12116.0.1.sock »после нескольких попыток», – Harshdeep

0

У пользователя, который запускает процесс apache, похоже, нет разрешения на чтение/запись из указанного места.

Обычно к ним подходят настройки директив WSGIDaemonProcess и WSGIProcessGroup в контейнере VirtualHost.

WSGIDaemonProcess process-name user=user group=group threads=10 python-path=vitrual-env-path 
WSGIProcessGroup process-group 

Вы можете также в качестве альтернативы (если нет никаких других проблем разрешения/групп.) Просто добавить соответствующий путь для чтения/записи к пользователю работает процесс Apache.

chmod [apache-user]+rw /etc/httpd/logs/ 
+0

На самом деле я проверил файл журнала wsgi, и это было 'srwx ------ 1 apache 0 Feb 28 07:14 wsgi.17555.5.1.sock'. Разве это не означает, что 'apache' уже имеют права на чтение/запись? – hobbes3

+0

Также я смущен вашей командой 'chmod'. Вы можете установить разрешение файла для определенного пользователя, в данном случае 'apache' ?? Например, пользователь и группа apache - 'apache'. Я не знаю, как узнать свою виртуальную среду python (или если мы даже используем ее). – hobbes3

+0

Если вы не используете virtual-env, вы можете спокойно проигнорировать эту часть. Если вы не знаете, вы, вероятно, нет. –

2

Я написал этот сценарий для обработки WSGI сокета проблемы разрешения на apache2-MPM-ITK

#!/bin/sh 
# This script will fix apache wsgi socket permissions 
# By default use standard socket location /var/run/apache2/wsgi 
# 
# You have to add this script after success execute of start|restart|reload 
# commands in next files: 
# /usr/sbin/apache2ctrl 
# /etc/init.d/apache2 

WSGISocketPrefix="/var/run/apache2/wsgi" 

if [ "$(id -u)" != "0" ]; then 
    echo "This script must be run as root" 1>&2 
    exit 1 
fi 

echo "Wait for other processes to start" 
sleep 1 
echo "Change wsgi socket permissions" 
chmod 0766 ${WSGISocketPrefix}.* 
Смежные вопросы