mod_wsgi的错误 - 类.__ dict__在受限模式下无法访问 [英] mod_wsgi error - class.__dict__ not accessible in restricted mode

查看：241
本文介绍了mod_wsgi的错误 - 类.__ dict__在受限模式下无法访问的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

这开始咬我们的屁股我们的生产服务器上真的很难。我们看到这个偶尔（每周1要求）。当时我们发现了那是因为的mod_wsgi的做一些时髦的东西在一些CONFIGS。由于我们无法跟踪的原因的错误，我们决定，它并不需要即时关注。

今天然而，在我们的生产服务器的1这真的发生了所有服务器请求的10％;这是所有服务器请求的10％，与此同样的错误失败：

 的mod_wsgi（PID = 1718）：目标WSGI脚本/installation/dir/our-program/prod-dispatch.wsgi不能加载Python模块。
mod_wsgi的（PID = 1718）：发生异常处理WSGI脚本/installation/dir/our-program/prod-dispatch.wsgi。
回溯（最近通话最后一个）：
  文件/installation/dir/our-program/prod-dispatch.wsgi，7号线，上述＆lt;＆模块GT;
    从pyramid.paster进口get_app
  文件\"/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/paster.py\", 12号线，上述＆lt;＆模块GT;
    从pyramid.scripting进口prepare
  文件\"/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/scripting.py\", 1号线，上述＆lt;＆模块GT;
    从pyramid.config进口global_registries
  文件\"/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/config/__init__.py\",线61，上述＆lt;模块＆GT;
    从pyramid.config.assets进口AssetsConfiguratorMixin
  文件\"/installation/dir/venv/local/lib/python2.7/site-packages/pyramid-1.3a6-py2.7.egg/pyramid/config/assets.py\",线83，上述＆lt;模块＆GT;
    @implementer（IPackageOverrides）
  文件\"/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py\",线480，在__
    classImplements（OB，* self.interfaces）
  文件\"/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py\",线445，CL中
    规格= implementedBy（CLS）
  文件\"/installation/dir/venv/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-linux-x86_64.egg/zope/interface/declarations.py\",线285，在IM
    规格= CLS .__字典__。获得（__ implemented__'）
RuntimeError：类.__ dict__在受限模式下无法访问

Ubuntu的precise，64位，与最新的阿帕奇，mod_wsgi的，Python 2.7版中的后台的模式下使用mpm_worker + mod_wsgi的。这是服务器上运行的唯一程序，并只存在一个WSGI $间在配置p $ PTER。这是因为mpm_worker产生新的线程或什么的？更重要的是 - 我们如何解决它。

。

我们有以下的细分要求的基础上的cookie 4守护进程。

  WSGIPythonOptimize 1WSGIDaemonProcess sticky01流程= 1线程= 16的显示名称=％{}集团
WSGIDaemonProcess sticky02流程= 1线程= 16的显示名称=％{}集团
WSGIDaemonProcess sticky03流程= 1线程= 16的显示名称=％{}集团
WSGIDaemonProcess sticky04流程= 1线程= 16的显示名称=％{}集团＆LT;虚拟主机*：81＆GT;
    ...
    WSGIRestrictProcess sticky01 sticky02 sticky03 sticky04
    WSGIProcessGroup％{ENV：PROCESS}
    ...    WSGIScriptAlias​​ / /installation/dir/our-program/prod-dispatch.wsgi
＆LT; /虚拟主机＆GT;


解决方案

已经知道了好半天多个subinter preters不沿C扩展打好。然而，我没有意识到的是，默认的设置是非常不幸的。 ModWSGI维基明确规定，对于WSGIApplicationGroup指令的默认值是％{}资源的其效果应是


  

的应用程序组名称将被设定为服务器的主机名和口
  作为％{SERVER}变量，向其中WSGI环境的值
  变量SCRIPT_NAME附加的文件分隔符分隔
  性格。


这意味着，每个主持人：在访问mod_wsgi的好心产生一个新subinter preTER，那么C扩展加载了服务器曾遇到的头

81的链接的这个本地服务器导致我们4 WSGIDaemonProcesses 1失败为将来所有的请求的浏览器

：

我不知不觉地通过访问localhost.invalid引发的错误

大全summarum：使用mod_wsgi的金字塔或使用C扩展，确保WSGIApplicationGroup总是被设置为％其他框架总是在全球{} 。换句话说，使用默认设置的结果将导致你搬起石头砸自己的脚，之后，你可能想搬起石头砸自己的头了。

This started biting our ass on our production server really hard. We saw this occasionally (for 1 request per week). Back then we found out it is because of mod_wsgi doing some funky stuff in some configs. As we could not track the reason for the bug, we decided that it did not require instant attention.

However today, on 1 of our production servers this really occurred for 10 % of all server requests; that is 10 % of all server requests failed with this very same error:

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, 64bit, with latest Apache, mod_wsgi, Python 2.7, using mpm_worker + mod_wsgi in daemon mode. This is the only program running on the server and there is only one wsgi interpreter in the config. Is this because of mpm_worker spawning new threads or what? More importantly - how do we fix it.

We have the following to subdivide requests to 4 daemon processes based on a cookie.

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>

解决方案

It has been known for ages that multiple subinterpreters don't play well along C extensions. However, what I did not realize is that the default settings are very unfortunate. ModWSGI wiki clearly states that the default value for WSGIApplicationGroup directive is %{RESOURCE} the effect of which shall be that

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.

This means that for each Host: header ever encountered while accessing the server the mod_wsgi kindly spawns a new subinterpreter, for which the C extensions are then loaded.

I had unknowingly triggered the error by accessing localhost.invalid:81 with links browser on this local server causing 1 of our 4 WSGIDaemonProcesses to fail for all future incoming requests.

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}. In other words, the result of using the default settings will cause you to shoot yourself in the foot, after which you might want to shoot yourself in the head too.

这篇关于mod_wsgi的错误 - 类.__ dict__在受限模式下无法访问的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
服务器开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆