2012-02-28 16 views
6

Przy próbie odwiedzenia mojej strony Django w http://www.satoshi.example.com/mysite dostaję 503 Service Temporary Unavailable.Django mod_wsgi apache

Dziennik błędów Apache mówi

[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 poprawnie wczytuje mod_wsgi

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

Apache ładunki /var/www/html/mysite/apache/apache_django_wsgi.conf co jest

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> 

To /var/www/html/mysite/apache/django.wsgi

Jedną z dziwnych rzeczy jest to, że dowiedziałem się, że nie muszę nawet LoadModule wsgi_module modules/mod_wsgi.so na własną httpd.conf. Myślę, że mój httpd.conf jest rozszerzeniem innej konfiguracji, która już załadowała mod_wsgi. Nie jestem pewien, czy to ma znaczenie.

Czy coś jest nie tak z tym, co przekazałem do tej pory? Daj mi znać, jeśli potrzebujesz więcej informacji. Z góry dziękuję!

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

informacji wymaganych przez @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 

informacji użytkownika (Czy chodziło Ci id? userid nie został znaleziony)

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

ls -la informacje

[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 do wysyłania dziennika apache. – jpic

Odpowiedz

9

Kwestia ta jest udokumentowana w:

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

Rozwiązania podane przez inne zmiany uprawnień są błędne.

Prawidłowe rozwiązanie to zmienić, gdzie przechowywane są pliki z gniazdem do miejsca, w którym użytkownik Apache może je odczytać.

W systemach, które chronią katalogu dzienników, czasami mieć system w miejsce, aby ustawić te uprawnienia z powrotem, kiedy bałagan z nimi. W rezultacie każda zmiana może być jedynie tymczasowa.

+0

Z mojego doświadczenia wynika, że ​​gdziekolwiek ustawisz lokalizację gniazda, zawsze będą mieć ostrzejsze uprawnienia (np. Srwx ------ www-data root), a więc musisz zmienić uprawnienia do gniazd. –

+1

Nie musisz i nie masz możliwości ustawiania uprawnień do gniazd, ponieważ nazwa pliku gniazda zmienia się dynamicznie w czasie na podstawie identyfikatora procesu, generowania konfiguracji Apache i wystąpienia grupy procesów demonów. IOW, to nie jest niezmienna nazwa. Dopóki katalog jest dostępny dla użytkownika Apache, wszystko będzie działało, ponieważ mod_wsgi zapewni, że rzeczywiste pliki gniazd mają odpowiednie uprawnienia. –

+1

@GrahamDumpleton Zmieniono konfigurację zgodnie z podanym linkiem, ale nadal pojawia się błąd "Nie można połączyć się z procesem demona WSGI" wsgi "na" /var/run/wsgi.12116.0.1.sock "po wielu próbach" – Harshdeep

0

Użytkownik, który uruchamia proces apache, nie ma uprawnień do odczytu/zapisu z podanej lokalizacji.

Zazwyczaj zbliża się to poprzez ustawienie dyrektyw WSGIDaemonProcess i WSGIProcessGroup w konfiguracji VirtualHost.

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

Można również alternatywnie (chyba, że ​​nie ma żadnych innych problemów pozwolenie/grupach.) Wystarczy dodać odpowiednią ścieżkę odczytu/zapisu dostępu do użytkownika uruchamiającego proces apache.

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

Właściwie sprawdziłem plik dziennika wsgi i było to 'srwx ------ 1 apache 0 Feb 28 07:14 wsgi.17555.5.1.sock'. Czy to nie oznacza, że ​​'apache' ma już uprawnienia do odczytu/zapisu? – hobbes3

+0

Również jestem zdezorientowany na twoim komendzie 'chmod'. Możesz ustawić uprawnienia do pliku dla określonego użytkownika, w tym przypadku 'apache' ?? Użytkownik i grupa apache to "apache". Nie wiem, jak dowiedzieć się mojego wirtualnego środowiska python (lub jeśli nawet używamy jednego). – hobbes3

+0

Jeśli nie używasz wirtualnego env, możesz bezpiecznie zignorować tę część. Jeśli nie wiesz, prawdopodobnie nie. –

2

ja napisałem ten skrypt do obsługi gniazd WSGI problemu pozwolenie na 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}.* 
Powiązane problemy