Calculer Girl
  1. Calculer Girl
  3. uWSGI, Flask, sqlalchemy et postgres: Erreur SSL: échec du déchiffrement ou enregistrement mac mauvais
Intereting Posts
Comment faire “diff -r” de UNIX dans Windows Cmd Prompt? Chemin UNC pointant vers le répertoire local beaucoup plus lentement que l’access local Y a-t-il quelque chose comme stream de données alternatifs sur tout système de fichiers Linux? Qu’est-ce qu’une règle mod_rewrite pour transformer * .html en * .php? Comment changer la valeur à httpd.conf à partir du script bash? le shell zsh illisible et le retour arrière ne fonctionnent pas sur le shell zsh sur Docker Comment définir l’heure serveur Amazon aws? Impossible de trouver le fichier / etc / sysconfig / clock Trouver tous les mots dans un fichier Unix qui commence par ‘#’ Services Web: EOF inattendu dans le prolog – Je comprends cela lorsque j’utilise Apache CXF et une méthode qui possède un paramètre POJO Comment puis-je utiliser Alt comme méta clé dans Windows pour Emacs 23, en particulier Mx? CentOS 6.5 + Apache Virtual Host Java JACOB extrait toutes les propriétés d’un object de classe Win32_ * donné Bibliothèque de modems / communications série gratuite ou application scriptable avec ZMODEM / KERMIT JAVA: diffuser n’importe quel fichier sur le navigateur correctement Avertissement de Sun Studio C ++ “ne se termine pas par une nouvelle ligne” – comment supprimer?

uWSGI, Flask, sqlalchemy et postgres: Erreur SSL: échec du déchiffrement ou enregistrement mac mauvais

J’essaie de configurer un serveur web d’application en utilisant uWSGI + Nginx, qui exécute une application Flask utilisant SQLAlchemy pour communiquer avec une firebase database Postgres.

Lorsque je fais des demandes au serveur Web, toute autre réponse sera une erreur 500.

L’erreur est: 

Traceback (most recent call last): File "/var/env/argos/lib/python3.3/site-packages/sqlalchemy/engine/base.py", line 867, in _execute_context context) File "/var/env/argos/lib/python3.3/site-packages/sqlalchemy/engine/default.py", line 388, in do_execute cursor.execute(statement, parameters) psycopg2.OperationalError: SSL error: decryption failed or bad record mac The above exception was the direct cause of the following exception: sqlalchemy.exc.OperationalError: (OperationalError) SSL error: decryption failed or bad record mac

L’erreur est déclenchée par une simple méthode Flask-SQLAlchemy : 

 result = models.Event.query.get(id)

uwsgi est géré par le supervisor , qui a une configuration: 

 [program:my_app] command=/usr/bin/uwsgi --ini /etc/uwsgi/apps-enabled/myapp.ini --catch-exceptions directory=/path/to/my/app stopsignal=QUIT autostart=true autorestart=true

et la uwsgi de uwsgi ressemble à: 

 [uwsgi] socket = /tmp/my_app.sock logto = /var/log/my_app.log plugins = python3 virtualenv = /path/to/my/venv pythonpath = /path/to/my/app wsgi-file = /path/to/my/app/application.py callable = app max-requests = 1000 chmod-socket = 666 chown-socket = www-data:www-data master = true processes = 2 no-orphans = true log-date = true uid = www-data gid = www-data

Le plus loin que je peux obtenir est que cela a quelque chose à voir avec le forking d’uwsgi. Mais au-delà, je ne sais pas ce qui doit être fait.

    Le problème a fini par être la création de uwsgi.

    Lorsque vous utilisez plusieurs processus avec un processus maître, uwsgi initialise l’application dans le processus maître, puis copie l’application dans chaque processus de travail. Le problème est que si vous ouvrez une connexion de firebase database lors de l’initialisation de votre application, vous avez alors plusieurs processus partageant la même connexion, ce qui provoque l’erreur ci-dessus.

    La solution consiste à définir l’ option de configuration différée pour uwsgi , qui impose un chargement complet de l’application dans chaque processus:

    lazy

    Définir le mode paresseux (charger des applications dans les travailleurs au lieu de maître).

    Cette option peut avoir des conséquences sur l’utilisation de la mémoire car la sémantique de la copie sur écriture ne peut pas être utilisée. Lorsque la paresse est activée, seuls les travailleurs seront rechargés par les signaux de rechargement de uWSGI; le maître restra en vie. En tant que tel, les modifications de configuration de uWSGI ne sont pas détectées lors du rechargement par le maître.

    Il y a aussi une option lazy-apps :

    lazy-apps

    Charger les applications dans chaque travailleur au lieu du maître.

    Cette option peut avoir des conséquences sur l’utilisation de la mémoire car la sémantique de la copie sur écriture ne peut pas être utilisée. Contrairement au paresseux, cela n’affecte que la façon dont les applications sont chargées, pas le comportement de maître lors du rechargement.

    Cette configuration uwsgi a fini par fonctionner pour moi: 

     [uwsgi] socket = /tmp/my_app.sock logto = /var/log/my_app.log plugins = python3 virtualenv = /path/to/my/venv pythonpath = /path/to/my/app wsgi-file = /path/to/my/app/application.py callable = app max-requests = 1000 chmod-socket = 666 chown-socket = www-data:www-data master = true processes = 2 no-orphans = true log-date = true uid = www-data gid = www-data # the fix lazy = true lazy-apps = true

    Comme alternative, vous pouvez disposer du moteur. C’est comme ça que j’ai résolu le problème.

    De tels problèmes peuvent survenir s’il y a une requête lors de la création de l’application, c’est-à-dire dans le module qui crée l’application elle-même. Si cela est indiqué, le moteur alloue un pool de connexions puis des fourches uwsgi.

    En appelant ‘engine.dispose ()’, le pool de connexions lui-même est fermé et de nouvelles connexions apparaissent dès que quelqu’un recommence à effectuer des requêtes. Donc, si vous le faites à la fin du module où vous créez votre application, de nouvelles connexions seront créées après le fork UWSGI.