Le problème a fini par être le forking d'uwsgi.
Lorsque vous travaillez avec plusieurs processus avec un processus maître, uwsgi initialise l'application dans le processus maître, puis copie l'application sur chaque processus de travail. Le problème est que si vous ouvrez une connexion à la base de données 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 est de définir le lazy option de configuration pour uwsgi, qui force un chargement complet de l'application à chaque processus :
lazyDéfinissez le mode paresseux (chargez les applications dans les nœuds de calcul au lieu du maître).
Cette option peut avoir des implications sur l'utilisation de la mémoire car la sémantique de copie sur écriture ne peut pas être utilisée. Lorsque le paresseux est activé, seuls les travailleurs seront rechargés par les signaux de rechargement d'uWSGI ; le maître restera en vie. Ainsi, les modifications de configuration uWSGI ne sont pas récupérées lors du rechargement par le maître.
Il y a aussi un lazy-apps choix :
lazy-appsChargez les applications dans chaque nœud de calcul au lieu du maître.
Cette option peut avoir des implications sur l'utilisation de la mémoire car la sémantique de 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 du 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
