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

[Raphael Hertzog]

Hello,

Le dimanche 03 octobre 2021, Sébastien Helleu a écrit :
> 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

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,
-- 
Raphaël Hertzog

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

[Sébastien Helleu]

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.

-- 
Sébastien Helleu

web: weechat.org / flashtux.org
irc: FlashCode @ irc.libera.chat

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

[Stephane Bortzmeyer]

Package: libapache2-mod-wsgi-py3
Version: 4.7.1-3+b1
Severity: normal

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 
[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 
[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 
.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.13.4-x86_64-linode146 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libapache2-mod-wsgi-py3 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.48-3.1+deb11u1
ii  libc6   2.31-13
ii  libpython3.93.9.2-1
ii  python3 3.9.2-3

libapache2-mod-wsgi-py3 recommends no packages.

libapache2-mod-wsgi-py3 suggests no packages.

-- no debconf information