2012-05-11 16 views
8

Esto comenzó a morder nuestro culo en nuestro servidor de producción realmente difícil. Vimos esto de vez en cuando (para 1 pedido por semana). En aquel entonces descubrimos que es debido a que mod_wsgi está haciendo algunas cosas funky en algunas configuraciones. Como no pudimos rastrear el motivo del error, decidimos que no requería atención instantánea.error de mod_wsgi - clase .__ dict__ no accesible en modo restringido

Sin embargo, hoy en día, en 1 de nuestros servidores de producción esto realmente ocurrió para el 10% de todas las solicitudes del servidor; es decir el 10% de todas las solicitudes de servidor que ha fallado con este mismo 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 precisa, de 64 bits, con la última Apache, mod_wsgi, Python 2.7, utilizando mpm_worker + mod_wsgi en demonio modo. Este es el único programa que se ejecuta en el servidor y solo hay un intérprete wsgi en la configuración. ¿Esto se debe a que mpm_worker está generando nuevos hilos o qué? Más importante aún, ¿cómo lo solucionamos?

Tenemos lo siguiente para subdividir solicitudes a 4 procesos de daemon basados ​​en una 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> 

Respuesta

9

Se sabe desde hace mucho tiempo que los subinterpreters múltiples no funcionan bien a lo largo de las extensiones C. Sin embargo, de lo que no me di cuenta es de que la configuración predeterminada es muy desafortunada. ModWSGI wiki establece claramente que el valor por defecto para directiva WSGIApplicationGroup es% {RECURSOS} cuyo efecto será el

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.

Esto significa que para cada cabecera Host: Alguna vez ha encontrado al acceder al servidor del mod_wsgi amablemente genera un nuevo subinterpreter , para lo cual las extensiones C se cargan.

sin saberlo, habían provocado el error al acceder localhost.invalid: 81 con enlaces navegador en este servidor local causando 1 de los 4 WSGIDaemonProcesses a fallar para todas las futuras solicitudes entrantes.

Summa summarum: siempre cuando se utiliza mod_wsgi con la pirámide o cualquier otra estructura que utiliza las extensiones C, asegúrese de que WSGIApplicationGroup siempre se establece en% {} GLOBAL. En otras palabras, el resultado de utilizar la configuración predeterminada provocará que se pegue un tiro en el pie, después del cual es posible que desee dispararse en la cabeza también.

+3

No todas las extensiones C tienen problemas, solo algunas. A veces esto se debe a la mala codificación en las extensiones C, otras veces el problema es que usan una API simplificada para manejar estados de hilos en Python. Entonces, aunque usar un grupo de procesos de daemon y forzar el uso del intérprete principal es una buena regla empírica, no siempre es necesario. –

+0

OK, gracias por la aclaración. Sin embargo, sigo creyendo que el% {RESOURCE} predeterminado es desafortunado ya que crea 2 subinterpreters para el mismo script wsgi en el mismo host virtual incluso cuando se accede con http://127.0.0.1 y http: // localhost. Es muy mágico. –

+1

% {RECURSO} debe usar el valor de ServerName del VirtualHost con el que coincide. Si no lo hace, entonces hay algún problema con la configuración de Apache se define. –

Cuestiones relacionadas