A questão acabou sendo a bifurcação do uwsgi.
Ao trabalhar com vários processos com um processo mestre, o uwsgi inicializa o aplicativo no processo mestre e copia o aplicativo para cada processo de trabalho. O problema é que se você abrir uma conexão de banco de dados ao inicializar seu aplicativo, você terá vários processos compartilhando a mesma conexão, o que causa o erro acima.
A solução é definir o
lazy opção de configuração para uwsgi, que força um carregamento completo da aplicação em cada processo:
lazy
Defina o modo lento (carregue aplicativos em workers em vez de master).
Essa opção pode ter implicações no uso de memória, pois a semântica Copy-on-Write não pode ser usada. Quando o lazy está habilitado, apenas os workers serão recarregados pelos sinais de recarregamento do uWSGI; o mestre permanecerá vivo. Como tal, as alterações de configuração do uWSGI não são selecionadas no recarregamento pelo mestre.
Há também um
lazy-apps opção:
lazy-apps
Carregue aplicativos em cada trabalhador em vez do mestre.
Essa opção pode ter implicações no uso de memória, pois a semântica Copy-on-Write não pode ser usada. Ao contrário do lazy, isso afeta apenas a maneira como os aplicativos são carregados, não o comportamento do mestre ao recarregar.
Esta configuração uwsgi acabou funcionando para mim:
[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
