Det slutade med att problemet blev uwsgi's forking.
När du arbetar med flera processer med en huvudprocess, initierar uwsgi applikationen i huvudprocessen och kopierar sedan applikationen till varje arbetsprocess. Problemet är att om du öppnar en databasanslutning när du initierar din applikation, har du flera processer som delar samma anslutning, vilket orsakar felet ovan.
Lösningen är att ställa in lazy konfigurationsalternativ för uwsgi, som tvingar fram en fullständig laddning av applikationen i varje process:
lazyStäll in lat läge (ladda in appar i arbetare istället för master).
Det här alternativet kan ha konsekvenser för minnesanvändning eftersom Copy-on-Write-semantik inte kan användas. När lazy är aktiverat kommer endast arbetare att laddas om av uWSGI:s omladdningssignaler; befälhavaren kommer att förbli vid liv. Som sådan plockas inte uWSGI-konfigurationsändringar upp vid omladdning av mastern.
Det finns också en lazy-apps alternativ:
lazy-appsLadda appar i varje arbetare istället för mastern.
Det här alternativet kan ha konsekvenser för minnesanvändning eftersom Copy-on-Write-semantik inte kan användas. Till skillnad från lazy påverkar detta bara hur applikationer laddas, inte mästarens beteende vid omladdning.
Den här uwsgi-konfigurationen slutade fungera för mig:
[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