Problemet endte med at blive uwsgi's forgrening.
Når du arbejder med flere processer med en masterproces, initialiserer uwsgi applikationen i masterprocessen og kopierer derefter applikationen til hver arbejdsproces. Problemet er, at hvis du åbner en databaseforbindelse, når du initialiserer dit program, har du flere processer, der deler den samme forbindelse, hvilket forårsager fejlen ovenfor.
Løsningen er at indstille lazy konfigurationsmulighed for uwsgi, som tvinger en fuldstændig indlæsning af applikationen i hver proces:
lazy
Indstil doven tilstand (indlæs apps i arbejdere i stedet for master).
Denne indstilling kan have hukommelsesbrugsimplikationer, da Copy-on-Write semantik ikke kan bruges. Når doven er aktiveret, vil kun arbejdere blive genindlæst af uWSGIs genindlæsningssignaler; mesteren vil forblive i live. Som sådan bliver uWSGI-konfigurationsændringer ikke opfanget ved genindlæsning af masteren.
Der er også en lazy-apps mulighed:
lazy-apps
Indlæs apps i hver arbejder i stedet for masteren.
Denne indstilling kan have hukommelsesbrugsimplikationer, da Copy-on-Write semantik ikke kan bruges. I modsætning til lazy påvirker dette kun måden, applikationer indlæses på, ikke mesterens adfærd ved genindlæsning.
Denne uwsgi-konfiguration endte med at virke for 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