Question

J'ai django courant à travers WSGI comme ceci:

<VirtualHost *:80>
    WSGIScriptAlias / /home/ptarjan/django/django.wsgi
    WSGIDaemonProcess ptarjan processes=2 threads=15 display-name=%{GROUP}
    WSGIProcessGroup ptarjan
    Alias /media /home/ptarjan/django/mysite/media/
</VirtualHost>

Mais si je le fais en python:

def handler(request) :
    data = urllib2.urlopen("http://example.com/really/unresponsive/url").read()

l'ensemble du serveur Apache se bloque et ne répond pas avec cette trace

#0  0x00007ffe3602a570 in __read_nocancel () from /lib/libpthread.so.0
#1  0x00007ffe36251d1c in apr_file_read () from /usr/lib/libapr-1.so.0
#2  0x00007ffe364778b5 in ?? () from /usr/lib/libaprutil-1.so.0
#3  0x0000000000440ec2 in ?? ()
#4  0x00000000004412ae in ap_scan_script_header_err_core ()
#5  0x00007ffe2a2fe512 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#6  0x00007ffe2a2f9bdd in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#7  0x000000000043b623 in ap_run_handler ()
#8  0x000000000043eb4f in ap_invoke_handler ()
#9  0x000000000044bbd8 in ap_process_request ()
#10 0x0000000000448cd8 in ?? ()
#11 0x0000000000442a13 in ap_run_process_connection ()
#12 0x000000000045017d in ?? ()
#13 0x00000000004504d4 in ?? ()
#14 0x00000000004510f6 in ap_mpm_run ()
#15 0x0000000000428425 in main ()

sur Debian Apache 2.2.11-7.

De même, pouvons-nous être protégés contre:

def handler(request) :
    while (1) :
        pass

En PHP, je fixais des limites de temps et de mémoire.

Était-ce utile?

La solution

Ce n'est pas le "délai d'interblocage" que vous souhaitez, comme spécifié par un autre, qui a un but très spécial et qui ne vous aidera pas dans ce cas.

En ce qui concerne l'utilisation des fonctionnalités de mod_wsgi, vous souhaitez plutôt l'option "inactivity-timeout" pour la directive WSGIDaemonProcess.

Même dans ce cas, ce n’est pas une solution complète. En effet, l'option 'inactivité-délai d'attente' sert à détecter si le traitement de toutes les demandes par un processus démon a cessé, il ne s'agit pas d'un délai d'attente par demande. Cela équivaut uniquement à un délai d'expiration par demande si les processus de démon sont à thread unique. En plus d'aider à décoller un processus, l'option aura également pour effet secondaire de redémarrer le processus démon si aucune demande n'arrive à ce moment-là.

En bref, il n’existe aucun moyen, au niveau mod_wsgi, d’avoir des délais d’expiration par requête, c’est qu’il n’existe aucun moyen réel d’interrompre une requête ou un thread en Python.

Ce que vous devez réellement implémenter est un délai d’expiration de la requête HTTP dans le code de votre application. Je ne suis pas sûr de savoir où il se trouve et s'il est déjà disponible, mais lancez une recherche Google sur "Délai d'attente de la prise urllib2".

Autres conseils

Si je comprends bien la question, vous souhaitez protéger Apache contre le blocage lors de l'exécution de scripts aléatoires par des personnes. Eh bien, si vous utilisez du code non fiable, je pense que vous devez vous inquiéter d’autres problèmes, qui sont pires qu’Apache.

Cela dit, vous pouvez utiliser certaines directives de configuration pour ajuster un environnement plus sûr . Ces deux éléments ci-dessous sont très utiles:

  • WSGIApplicationGroup : définit le groupe d'applications auquel l'application WSGI appartient. Il permet de séparer les paramètres de chaque utilisateur. Toutes les applications WSGI d’un même groupe s’exécutent dans le contexte du même sous-interpréteur Python du processus traitant la demande.

  • WSGIDaemonProcess : configure un processus démon distinct pour l'exécution d'applications. Les processus démons peuvent être exécutés en tant qu'utilisateur différent de celui utilisé normalement pour les processus enfants Apache. Cette directive accepte de nombreuses options utiles, je vais en énumérer quelques-unes:

    • utilisateur = nom | utilisateur = # uid , groupe = nom | group = # gid :

      Définit le nom d'utilisateur ou de groupe UNIX ou le nom d'utilisateur numérique ou le gid de groupe de l'utilisateur / du groupe selon lequel le processus démon doit être exécuté.

    • pile-taille = nnn

      La quantité de mémoire virtuelle en octets à allouer pour la pile correspondant à chaque thread créé par mod_wsgi dans un processus démon.

    • deadlock-timeout = sss

      Définit le nombre maximal de secondes autorisé avant l'arrêt et le redémarrage du processus démon après détection d'un éventuel blocage sur Python GIL. La valeur par défaut est 300 secondes.

Pour en savoir plus sur les directives de configuration, cliquez ici .

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top