Development #26911
authentic: empêcher celery/kombu de manipuler le timeout par défaut des sockets
0%
Description
Actuellement la notification se fait dans un thread qui partage malheureusement
ce timeout avec le reste d'authentic, le but ici est de remplacer cela par un
simple os.fork().
Fichiers
Demandes liées
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
- Fichier 0002-authentic-send-celery-notification-in-a-child-proces.patch 0002-authentic-send-celery-notification-in-a-child-proces.patch ajouté
- Fichier 0001-tests-simplify-fixture-using-standard-ones-26911.patch 0001-tests-simplify-fixture-using-standard-ones-26911.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Le premire patch c'est kdo.
Le deuxième c'est assez moche et j'ai du pas mal me contorsionner pour arriver
à vérifier que notify_agents() était bien appelé dans le processus fils (et je
me dis que ça pourrait tout de même foirer si jamais les pickles posé dans la
queue dépasse la taille de buffer des pipes système, en effet il y a un
potentiel deadlock entre le waitpid() dans le parent et l'écriture dans le pipe
qui empêche l'appel à exit() si ça bloque, mais ça ne concerne que les tests).
En attendant ça semble marcher et les tests passent (reste à faire un test
grandeur nature).
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
- Statut changé de Solution proposée à Nouveau
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
- Tracker changé de Support à Development
- Statut changé de Nouveau à Solution proposée
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
- Fichier 0002-authentic-send-celery-notification-in-a-child-proces.patch 0002-authentic-send-celery-notification-in-a-child-proces.patch ajouté
- Fichier 0001-tests-simplify-fixture-using-standard-ones-26911.patch 0001-tests-simplify-fixture-using-standard-ones-26911.patch ajouté
Rebasé.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
- Statut changé de Solution proposée à En cours
À refaire via un worker uwsgi quand a2 y sera passé.
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Statut changé de En cours à Rejeté
Personne ne semble embêter par ce problème qui peut-être n'existe plus.
Mis à jour par Frédéric Péters il y a environ 2 ans
Modulo les problèmes de timeout LDAP en pagaille qui pourraient être ça ? (#60277)
Mis à jour par Emmanuel Cazenave il y a environ 2 ans
- Lié à Bug #26351: Forcer le timeout des socket de mail ajouté
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Statut changé de Rejeté à Nouveau
Pas impossible oui.
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Fichier 0001-misc-fork-before-sending-message-to-celery-26911.patch 0001-misc-fork-before-sending-message-to-celery-26911.patch ajouté
- Statut changé de Nouveau à Solution proposée
Voilà, très très simple, à tester en live.
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Statut changé de Solution proposée à Rejeté
Mais c'est idiot en fait, on utilise plus le provisionning celery nul part vu que c'est à True par défaut partout, ce bug n'existe plus.
Mis à jour par Emmanuel Cazenave il y a environ 2 ans
Mais l'agent a2 écoute reçǫit quand même les messages de déploiement via celery/kombu.
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
Emmanuel Cazenave a écrit :
Mais l'agent a2 écoute reçǫit quand même les messages de déploiement via celery/kombu.
Le souci c'est ce qui se passe dans les process authentic (là où sont faits les appels SMTP pour le problème précédent, et maintenant les appels LDAP), et la seule partie du provisionning dans a2 c'est l'émission des messages, et maintenant ça n'utilise qu'HTTP et plus Celery/AMQP. Il n'en reçoit pas et s'il en recevait ce serait via le process de l'agent de toute façon. L'agent il ne tourne pas dans a2, tout va bien.
Mis à jour par Frédéric Péters il y a environ 2 ans
Je n'ai pas cherché où celery faisait sa modification de timeout, si c'est à l'import de fait la présence de hobo.agent.common dans INSTALLED_APPS suffirait à casser les choses.
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
Frédéric Péters a écrit :
Je n'ai pas cherché où celery faisait sa modification de timeout, si c'est à l'import de fait la présence de hobo.agent.common dans INSTALLED_APPS suffirait à casser les choses.
Un rapide import socket; def f(*args, **kwargs); raise Exception; socket.setdefaulttimeout = f en début des script manage.py puis un shell ne m'a pas permis de découvrir d'appel à cette fonction lors de l'initialisation de Django. Le plus simple ce serait de virer complètement hobo.agent.common.notify_agents et de voir ce que ça donne.
Mis à jour par Emmanuel Cazenave il y a environ 2 ans
Frédéric Péters a écrit :
Je n'ai pas cherché où celery faisait sa modification de timeout, si c'est à l'import de fait la présence de hobo.agent.common dans INSTALLED_APPS suffirait à casser les choses.
Ce n'est pas à l'import (https://github.com/celery/kombu/blob/master/kombu/connection.py#L350), Benjamin doit avoir raison (j'oubliais que a2 et l'agent a2 sont dans des processus différents).