#994040 "SystemError: initialization of _psycopg raised unreported exception" when running under WSGI

Package:
libapache2-mod-wsgi-py3
Source:
mod-wsgi
Description:
Python 3 WSGI adapter module for Apache
Submitter:
Stephane Bortzmeyer
Date:
2021-10-21 21:21:04 UTC
Severity:
normal
#994040#5
Date:
2021-09-10 14:16:39 UTC
From:
To:
Dear Maintainer,

Since upgrading to bullseye, a WSGI script which imports psycopg2
fails sometimes (randomly?) with:

[Sun Aug 29 17:54:07.215719 2021] [wsgi:error] [pid 7705] [client 127.0.0.1:33774] mod_wsgi (pid=7705): Exception occurred processing WSGI script '/var/www/wsgis-bortzmeyer/ni.py'.
[Sun Aug 29 17:54:07.215893 2021] [wsgi:error] [pid 7705] [client 127.0.0.1:33774] Traceback (most recent call last):
[Sun Aug 29 17:54:07.215967 2021] [wsgi:error] [pid 7705] [client 127.0.0.1:33774]   File "/var/www/wsgis-bortzmeyer/ni.py", line 11, in <module>
[Sun Aug 29 17:54:07.216000 2021] [wsgi:error] [pid 7705] [client 127.0.0.1:33774]     import psycopg2
[Sun Aug 29 17:54:07.216026 2021] [wsgi:error] [pid 7705] [client 127.0.0.1:33774]   File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 51, in <module>
[Sun Aug 29 17:54:07.216051 2021] [wsgi:error] [pid 7705] [client 127.0.0.1:33774]     from psycopg2._psycopg import (                     # noqa
[Sun Aug 29 17:54:07.216087 2021] [wsgi:error] [pid 7705] [client 127.0.0.1:33774] SystemError: initialization of _psycopg raised unreported exception

psycopg2 on the same machine always work when ran outside of WSGI.

Setting WSGIApplicationGroup %{GLOBAL} in the configuration cures the
problem.

I checked that there is only one Python (the Debian package) on the
machine.

A similar case is reported in <https://stackoverflow.com/questions/67673276/import-psycopg2-systemerror-initialization-of-psycopg-raised-unreported-exce>.
#994040#10
Date:
2021-10-03 08:01:37 UTC
From:
To:
Hi Stéphane,

I've hit the same problem while migrating my Django sites from Debian Buster to
Bullseye.

In my case, setting "WSGIApplicationGroup" to "%{GLOBAL}" doesn't help much.

But I found another solution, by enabling Daemon mode, as recommended by the
Django docs:
https://docs.djangoproject.com/en/3.2/howto/deployment/wsgi/modwsgi/#using-mod-wsgi-daemon-mode

So I added these two lines in each site (with appropriate domain name) and it
works fine:

WSGIDaemonProcess example.com
WSGIProcessGroup example.com

Hope it helps.
#994040#15
Date:
2021-10-21 21:18:11 UTC
From:
To:
Hello,

Le dimanche 03 octobre 2021, Sébastien Helleu a écrit :

When we upgraded tracker.debian.org to bullseye, we were already using
"daemon mode" as recommended by the documentation but we still had the
above issue and setting "WSGIApplicationGroup" to "%{GLOBAL}" did
indeed fix the issue for us.

Adrian Bunk thinks that it could be fixed by
https://github.com/GrahamDumpleton/mod_wsgi/commit/9509e178e0583435a800b006b410df74e405e2b9

It would be nice if someone could double check that... we don't want to
use tracker.debian.org for that kind of test.

Cheers,