这开始对我们的生产服务器造成严重影响。我们偶尔会看到这种情况(每周 1 个请求)。那时我们发现这是因为 mod_wsgi 在某些配置中做了一些奇怪的事情。由于我们无法追踪错误的原因，我们决定不需要立即关注它。

但是今天，在我们的一台生产服务器上，确实发生了所有服务器请求的 10%；也就是说，所有服务器请求中有 10% 因同样的错误而失败:

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

Ubuntu Precise，64 位，带有最新的 Apache、mod_wsgi、Python 2.7，在 daemon 模式下使用 mpm_worker + mod_wsgi。这是服务器上运行的唯一程序，配置中只有一个 wsgi 解释器。这是因为 mpm_worker 产生了新线程还是什么？更重要的是 - 我们如何解决它。

我们有以下根据cookie将请求分割到4个守护进程。

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>

最佳答案

众所周知，多个子解释器在 C 扩展中表现不佳。但是，我没有意识到默认设置非常不幸。 ModWSGI wiki明确指出 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: header ，mod_wsgi 会友好地生成一个新的子解释器，然后为其加载 C 扩展。

我在这台本地服务器上使用链接浏览器访问 localhost.invalid:81 时无意中触发了错误，导致我们的 4 个 WSGIDaemonProcesses 中的 1 个对于所有 future 的传入请求都失败。

总结:始终在将 mod_wsgi 与 Pyramid 或使用 C 扩展的任何其他框架一起使用时，确保 WSGIApplicationGroup 始终设置为 %{GLOBAL}。换句话说，使用默认设置的结果将导致您搬起石头砸自己的脚，之后您可能还想搬起石头砸自己的头。

关于python - mod_wsgi 错误 - class.__dict__ 在受限模式下不可访问，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10557930/