Обслуживание двух сайтов Django с результатами WSGI с ошибкой внутреннего сервера только для одного из сайтов

Question

У меня есть сайт Django и сайт Django CMS, который я обслуживаю с того же сервера Ubuntu 14.04 с MySQL 5.6, Apache2 2.4.7 и Django 1.8 с помощью mod_wsgi версии 4.5.7 с использованием виртуальных хостов. Локально (на моем Linux-ПК) мне удалось добиться этого, работая на обоих сайтах, и, следовательно, решила перейти на сервер.

После миграции, заботясь о том, что все имеет одинаковую версию, ситуация такова, что сайт Django работает правильно, а сайт Django CMS дает мне и внутреннюю ошибку сервера 500. Это мои виртуальные хосты .conf файлы и файл wsgi.py для сломанного сайта.

# wsgi.py 
import os 
from django.core.wsgi import get_wsgi_application 
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "bsg.settings") 
application = get_wsgi_application() 

# Django_cms_site.conf 
<VirtualHost *:80> 
    ServerName site.com 
    ServerAdmin webmaster@localhost.com 

    Alias /static/ /home/bsg/cms/static/ 
    Alias /media/ /home/bsg/cms/media/ 

    WSGIScriptAlias//home/bsg/cms/bsg/wsgi.py 
    WSGIDaemonProcess bsgcms python-path=/home/hicklin/bsg/cms:/home/venv-bsg/lib/python2.7/site-packages 
    WSGIProcessGroup bsgcms 

    <Directory /home/bsg/cms> 
     Require all granted 
    </Directory> 

    LogLevel warn 
    ErrorLog /var/log/apache2/cms-error.log 
    CustomLog /var/log/apache2/cms-access.log combined 
</VirtualHost> 

# Django_site.conf 
<VirtualHost *:80> 
    ServerName django.site.com 
    ServerAdmin webmaster@localhost.com 

    Alias /static/ /home/bsg/admin/site/static/ 

    WSGIScriptAlias//home/bsg/admin/site/wsgi.py 
    WSGIDaemonProcess bsgadmin python-path=/home/bsg/admin:/home/hicklin/venv-bsg/lib/python2.7/site-packages 
    WSGIProcessGroup bsgadmin 

    <Directory /home/bsg/admin> 
     Require all granted 
    </Directory> 

    LogLevel warn 
    ErrorLog /var/log/apache2/admin-error.log 
    CustomLog /var/log/apache2/admin-access.log combined 
</VirtualHost> 

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

[Tue Oct 11 22:39:43.416901 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984] mod_wsgi (pid=19799): Target WSGI script '/home/bsg/cms/bsg/wsgi.py' cannot be loaded as Python module. 
[Tue Oct 11 22:39:43.416942 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984] mod_wsgi (pid=19799): Exception occurred processing WSGI script '/home/bsg/cms/bsg/wsgi.py'. 
[Tue Oct 11 22:39:43.416977 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984] Traceback (most recent call last): 
[Tue Oct 11 22:39:43.417014 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984] File "/home/bsg/cms/bsg/wsgi.py", line 16, in <module> 
[Tue Oct 11 22:39:43.417067 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984]  application = get_wsgi_application() 
[Tue Oct 11 22:39:43.417093 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984] File "/home/venv-bsg/lib/python2.7/site-packages/django/core/wsgi.py", line 14, in get_wsgi_application 
[Tue Oct 11 22:39:43.417134 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984]  django.setup() 
[Tue Oct 11 22:39:43.417158 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984] File "/home/venv-bsg/lib/python2.7/site-packages/django/__init__.py", line 18, in setup 
[Tue Oct 11 22:39:43.417194 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984]  apps.populate(settings.INSTALLED_APPS) 
[Tue Oct 11 22:39:43.417217 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984] File "/home/venv-bsg/lib/python2.7/site-packages/django/apps/registry.py", line 78, in populate 
[Tue Oct 11 22:39:43.417255 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984]  raise RuntimeError("populate() isn't reentrant") 
[Tue Oct 11 22:39:43.417289 2016] [wsgi:error] [pid 19799] [remote 77.71.226.73:64984] RuntimeError: populate() isn't reentrant 

После изменения wsgi.py, чтобы получить реальную ошибку как предложил Дирк Eschler в the thread, ошибка в /var/log/apache2/cms-error.log изменений

[Tue Oct 11 21:36:06.087723 2016] [wsgi:error] [pid 21584] handling WSGI exception 
[Tue Oct 11 21:36:06.087811 2016] [wsgi:error] [pid 21584] Traceback (most recent call last): 
[Tue Oct 11 21:36:06.087854 2016] [wsgi:error] [pid 21584] File "/home/bsg/cms/bsg/wsgi.py", line 9, in <module> 
[Tue Oct 11 21:36:06.087975 2016] [wsgi:error] [pid 21584]  application = get_wsgi_application() 
[Tue Oct 11 21:36:06.087996 2016] [wsgi:error] [pid 21584] File "/home/venv-bsg/lib/python2.7/site-packages/django/core/wsgi.py", line 14, in get_wsgi_application 
[Tue Oct 11 21:36:06.088067 2016] [wsgi:error] [pid 21584]  django.setup() 
[Tue Oct 11 21:36:06.088093 2016] [wsgi:error] [pid 21584] File "/home/venv-bsg/lib/python2.7/site-packages/django/__init__.py", line 17, in setup 
[Tue Oct 11 21:36:06.088164 2016] [wsgi:error] [pid 21584]  configure_logging(settings.LOGGING_CONFIG, settings.LOGGING) 
[Tue Oct 11 21:36:06.088190 2016] [wsgi:error] [pid 21584] File "/home/venv-bsg/lib/python2.7/site-packages/django/conf/__init__.py", line 48, in __getattr__ 
[Tue Oct 11 21:36:06.088366 2016] [wsgi:error] [pid 21584]  self._setup(name) 
[Tue Oct 11 21:36:06.088388 2016] [wsgi:error] [pid 21584] File "/home/venv-bsg/lib/python2.7/site-packages/django/conf/__init__.py", line 42, in _setup 
[Tue Oct 11 21:36:06.088417 2016] [wsgi:error] [pid 21584]  % (desc, ENVIRONMENT_VARIABLE)) 
[Tue Oct 11 21:36:06.088442 2016] [wsgi:error] [pid 21584] ImproperlyConfigured: Requested setting LOGGING_CONFIG, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings. 
[Tue Oct 11 21:36:08.591950 2016] [wsgi:error] [pid 21584] [remote 77.71.226.73:3851] mod_wsgi (pid=21584): Target WSGI script '/home/bsg/cms/bsg/wsgi.py' does not contain WSGI application 'application'. 

Обратите внимание, что мне удалось запустить, получить доступ и работать на сайте cms с помощью python manage.py runningerver, и он работает без сбоев. После последней ошибки ничего еще не принесло. Любая помощь или намеки приветствуются.

Answer 1

Это связано с тем, что ваша база данных или какой-либо другой ресурс, необходимый при инициализации Django, недоступен, или инициализация Django в противном случае провалилась каким-то другим способом в первый раз. Вовремя инициализация Django была реентерабельной и могла быть вызвана во второй раз, если в первый раз она потерпела неудачу. Это уже не так, поэтому, если инициализация завершилась неудачно в первый раз, вам придется перезапустить процесс.

Поскольку вы используете последнюю версию mod_wsgi, вы должны иметь возможность добавить дополнительную опцию в WSGIDaemonProcess для решения этой проблемы.

startup-timeout=15 

Что будет происходить в том, что если mod_wsgi не может успешно загрузить файл WSGI скрипт в течение 15 секунд после первой попытки сделать это так, то процесс демон mod_wsgi будет автоматически перезапущен. Он будет продолжать делать это, если он продолжает терпеть неудачу из-за того, что некоторая служба, требуемая во время инициализации, недоступна.

Кстати, должно быть более раннее сообщение об ошибке в журнале ошибок, чем то, что дало истинную причину неудачи инициализации. Это сообщение, которое вы цитируете, связано с последующими сбоями после первого. Я не верю, что другое сообщение, которое вы даете, верное, поэтому вернитесь назад и найдите первое сообщение после перезапуска Apache.

Наконец, лучшая практика не использовать:

WSGIDaemonProcess bsgadmin python-path=/home/bsg/admin:/home/hicklin/venv-bsg/lib/python2.7/site-packages 

но:

WSGIDaemonProcess bsgadmin python-home=home/hicklin/venv-bsg python-path=/home/bsg/admin 

То есть, использовать python-home параметр, чтобы указать местоположение виртуальной среде Python, не добавляйте site-packages в python-path.См:

• http://blog.dscpl.com.au/2014/09/using-python-virtual-environments-with.html

Answer 2

Добавление startup-timeout=15 к WSGIDaemonProcess в виртуальных хостов конфигурационный файл не решить мою проблему.

Что касается «более раннего сообщения об ошибке в журнале ошибок» с измененным wsgi.py, чтобы получить реальную ошибку, единственные ошибки, присутствующие в /var/log/apache2/cms-error.log, по-видимому, связаны с тем, что «Target WSGI-скрипт не содержит WSGI приложение «приложение». Как указано в вопросе. Проверка журнала ошибок apache2 во время перезагрузки и последующих попыток загрузки сайта показала типичный выход.

[Wed Oct 12 16:16:01.372050 2016] [mpm_prefork:notice] [pid 23564] AH00169: caught SIGTERM, shutting down 
[Wed Oct 12 16:16:02.292367 2016] [mpm_prefork:notice] [pid 1169] AH00163: Apache/2.4.7 (Ubuntu) mod_wsgi/4.5.7 Python/2.7 PHP/5.5.9-1ubuntu4.20 configured -- resuming normal operations 
[Wed Oct 12 16:16:02.292455 2016] [core:notice] [pid 1169] AH00094: Command line: '/usr/sbin/apache2' 

Наконец-то, что работало, это отформатировать сервер и начать все заново. Mod_WSGI теперь отлично работает с обоими сайтами. Я также обновился до MySQL 5.7 и ubuntu 16.04.

Я хотел бы указать, что окончательное предложение о том, как установить python-path и python-home, не работало со старой системой, однако оно работало без каких-либо проблем в новой системе. Это заставляет меня думать, что я каким-то образом установил модифицированный mod-WSGI или он был поврежден во время установки. Я не уверен в этом.