Вопрос по wsgi, mod-wsgi, apache, python, pyramid – Ошибка mod_wsgi - класс .__ dict__ недоступен в ограниченном режиме

8

Это начало очень сильно кусать нашу задницу на нашем производственном сервере. Мы видели это иногда (для 1 запроса в неделю). В то время мы узнали, что это происходит из-за того, что mod_wsgi делает некоторые интересные вещи в некоторых конфигах. Поскольку мы не могли отследить причину ошибки, мы решили, что она не требует немедленного внимания.

Однако сегодня на одном из наших производственных серверов это действительно происходит для 10% всех запросов к серверу; то есть 10% всех запросов к серверу не удалось с этой же ошибки:

<code>mod_wsgi (pid=1718): Target WSGI script '/installation/dir/our-program/prod-dispatch.wsgi' cannot be loaded as Python module.
mod_wsgi (pid=1718): Exception occurred processing WSGI script '/installation/dir/our-program/prod-dispatch.wsgi'.
Traceback (most recent call last):
  File "/installation/dir/our-program/prod-dispatch.wsgi", line 7, in <module>
    from pyramid.paster import get_app
  File "/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/paster.py", line 12, in <module>
    from pyramid.scripting import prepare
  File "/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/scripting.py", line 1, in <module>
    from pyramid.config import global_registries
  File "/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/config/__init__.py", line 61, in <module>
    from pyramid.config.assets import AssetsConfiguratorMixin
  File "/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/config/assets.py", line 83, in <module>
    @implementer(IPackageOverrides)
  File "/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py", line 480, in __
    classImplements(ob, *self.interfaces)
  File "/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py", line 445, in cl
    spec = implementedBy(cls)
  File "/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py", line 285, in im
    spec = cls.__dict__.get('__implemented__')
RuntimeError: class.__dict__ not accessible in restricted mode
</code>

Ubuntu Precise, 64-битная, с последним Apache, mod_wsgi, Python 2.7, использующим mpm_worker + mod_wsgi вdaemon Режим. Это единственная программа, работающая на сервере, и в конфигурации есть только один интерпретатор wsgi. Это из-за того, что mpm_worker порождает новые темы или как? Более важно - как мы это исправим.

У нас есть следующее, чтобы разделить запросы к 4 процессам демона на основе куки.

<code>WSGIPythonOptimize 1

WSGIDaemonProcess sticky01 processes=1 threads=16 display-name=%{GROUP}
WSGIDaemonProcess sticky02 processes=1 threads=16 display-name=%{GROUP}
WSGIDaemonProcess sticky03 processes=1 threads=16 display-name=%{GROUP}
WSGIDaemonProcess sticky04 processes=1 threads=16 display-name=%{GROUP}

<VirtualHost *:81>
    ...
    WSGIRestrictProcess sticky01 sticky02 sticky03 sticky04
    WSGIProcessGroup %{ENV:PROCESS}
    ...

    WSGIScriptAlias / /installation/dir/our-program/prod-dispatch.wsgi        
</VirtualHost>
</code>

Ваш Ответ

1   ответ
10

Уже давно известно, что несколько субинтерпретаторов не очень хорошо играют на C-расширениях. Однако я не понял, что настройки по умолчанию очень неудачны.ModWSGI вики ясно указывает, что значением по умолчанию для директивы WSGIApplicationGroup является% {RESOURCE}, результатом которого должно быть

The application group name will be set to the server hostname and port as for the %{SERVER} variable, to which the value of WSGI environment variable SCRIPT_NAME is appended separated by the file separator character.

Это означает, что для каждого заголовка Host:, который когда-либо встречался при обращении к серверу, mod_wsgi любезно порождает нового субинтерпретатора, для которого затем загружаются расширения C.

Я невольно вызвал ошибку, обратившись к localhost.invalid: 81 сlinks браузер на этом локальном сервере, вызывая сбой 1 из 4 наших WSGIDaemonProcesses для всех будущих входящих запросов.

Summa summarum:always when using mod_wsgi with pyramid or any other framework that uses C extensions, make sure that WSGIApplicationGroup is always set to %{GLOBAL}, Другими словами, результат использования настроек по умолчанию заставит вас выстрелить себе в ногу, после чего вы также можете захотеть выстрелить себе в голову.

Не все расширения C имеют проблемы, только определенные. Иногда это происходит из-за плохого кодирования в расширениях C, в других случаях проблема заключается в том, что они используют упрощенный API для обработки состояний потоков в Python. Таким образом, хотя использование группы процессов демона и принудительное использование основного интерпретатора является хорошим практическим правилом, это не всегда необходимо.
ОК, спасибо за разъяснения. Тем не менее, я по-прежнему считаю, что значение по умолчанию% {RESOURCE} является неудачным, поскольку оно создает 2 субинтерпретатора для одного и того же сценария wsgi на одном виртуальном хосте, даже при обращении к нему с помощью127.0.0.1 а такжеlocalhost, Это слишком волшебно. Antti Haapala
% {RESOURCE} должен использовать значение ServerName из VirtualHost, которому он соответствует. Если это не так, то существует определенная проблема с конфигурацией Apache.
Но это не NameVirtualHost, это просто порт, он не содержит ServerName. Antti Haapala

Похожие вопросы