Hello Graham,
many thanks for your kind and detailed help!
Best regards,
Carsten
Am 10.02.23 um 01:07 schrieb Graham Dumpleton:
> Use WSGIApplicationGroup to force the use of the main Python sub interpreter.
> That is only safe way to deal with it.
>
> I have created issue against CPython
Argh, sorry, I think I may have spoken too soon: The deadsnakes PPA does not
contain Python 3.10 for Ubuntu 22.04 and I'm not really prepared to compile
from source.
Would it help you, mod_wsgi or someone else if I pursued installing the latest
Python 3.10 point release for further testing?
Many thanks for your help and the detailed information!
My Python version is 3.10.6.
I'll try to switch to the latest point release next, but it will a couple of
days before I can do it. Will let you know the results as soon as I got it done.
Best regards,
Carsten
Am 08.02.23 um 21:28 schrieb
Possibly related issues:
https://bugs.archlinux.org/task/72979
https://bugs.python.org/issue46006
There are possibly some known issues with sub interpreters in code used by
sqlite module there.
What exact version of Python 3.10 as you using? Can you update to latest patch
revision of it?
More specifically, if you look at the stack trace you see:
#6 0x7f68aefe6292 in PyEval_RestoreThread () from
target:/lib/x86_64-linux-gnu/libpython3.10.so.1.0
#7 0x7f68af02f1dc in PyGILState_Ensure () from
target:/lib/x86_64-linux-gnu/libpython3.10.so.1.0
#8 0x7f68ac30d6e3 in ??
The key bit of information in that is the call to
sqlite3LeaveMutexAndCloseZombie(). It looks like sqlite module for Python is
doing something really strange that isn't working with sub interpreters. This
will need some research as it may be a bug they have introduced in Python 3.10
for the
Ok, I got a stack trace. My understanding of this is limited, but the thread
seems to be stuck at polling something without timeout? (gdb reports that file
../sysdeps/unix/sysv/linux/poll.c cannot be found)
The full session follows. (Using plaintext email today in the hope that this
helps with
Only other thing can suggest if you know point at which it is hanging, is to
test and extract C stack trace by attaching gdb to the running process. This
may or may not work depending on your system setup and what tools are installed.
Is any of your code using ctypes module for Apache, or any other module which
is used to call into C code by writing Python code only?
Graham
> On 8 Feb 2023, at 2:55 am, Carsten Fuchs wrote:
>
> Hello,
>
> hmmm. There are no .so files there:
>
> $ pwd
>
Hello,
hmmm. There are no .so files there:
$ pwd
/home/carsten/.virtualenvs/HallCam-web/lib/python3.10/site-packages
$ dir
insgesamt 120
drwxrwxr-x 3 carsten carsten 4096 Feb 6 20:41 asgiref
drwxrwxr-x 2 carsten carsten 4096 Feb 6 20:41 asgiref-3.6.0.dist-info
drwxrwxr-x 6 carsten
Go into the lib/python3.10/site-packages directory of your Python virtual
environment. What .so files exist in that directory? These are the packages
with C extensions. It is only code in C extensions that should normally be able
to trigger a Python deadlock.
Graham
> On 7 Feb 2023, at 7:14
Hello Graham,
many thanks for your detailed reply!
I must add that my Django project is a simple webcam application: A webcam
sends POST requests to upload the images, the views show them. A single webcam
is connected over a very slow internet connection (32 kBit/s), so a single POST
can take
Two points here to clarify.
In your case the final error is:
Daemon process deadlock timer expired
This means that the full Python interpreter locked up. In this case the request
timeout may not apply and the feature where by stack traces can be dumped might
not happen. Depends on what lead
Adding to my recent post:
It seems that the `request-timeout=30` is effective, after all: The error
messages have changed, but there is no stack trace.
For completeness, here is the site config and error log excerpt:
Site config:
ServerAdmin webmaster@localhost
DocumentRoot
Dear Graham,
It was a matter of adding that line and everything fell into place!
Thanks a lot,
A
On Monday, January 23, 2023 at 8:21:44 PM UTC+1 Graham Dumpleton wrote:
> Your configuration means only a single request can be handled at a time by
> the daemon process, so if you have a very
Your configuration means only a single request can be handled at a time by the
daemon process, so if you have a very long running request, any other requests
would block waiting.
Even if not a long running request, a problem may be that you are using a
Python package that isn't designed to
16 matches
Mail list logo
