Dear Graham,

I experienced the same timeout errors after having upgraded a server from 
Ubuntu 20.04 LTS to Ubuntu 22.04 LTS, thereby also upgrading from Python 
3.8 to Python 3.10. The application is a relatively simple Django project 
that used to work well until the upgrade. After the upgrade, I deleted the 
old virtualenv and built a new one, using `pip install --no-cache-dir -r 
requirements.txt` to install it. However, I experience the same problem.

Adding `WSGIApplicationGroup %{GLOBAL}` solved the problem, but I am still 
concerned because the site worked well with the older Ubuntu 20.04 LTS and 
I would prefer to not mask a potential problem and rather find its root.

Therefore, I added the `request-timeout=30` option to `WSGIDaemonProcess` 
(and temporarily commented `WSGIApplicationGroup` out again) in order to 
get a stack trace, however it doesn't seem to have any effect: Requests 
time out only much later than 30 seconds.

Can you please advise what may have caused the problem when upgrading from 
Ubuntu 20.04 LTS to Ubuntu 22.04 LTS and why `request-timeout=30` may not 
have any effect?

Best regards,
Carsten

A schrieb am Dienstag, 24. Januar 2023 um 10:39:40 UTC+1:

> 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 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 work in a Python sub interpreter. 
>> This could cause that package to hang and so everything blocks up (same as 
>> long running request at that point) for that request.
>>
>> Application Issues — mod_wsgi 4.9.4 documentation 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#python-simplified-gil-state-api>
>> modwsgi.readthedocs.io 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#python-simplified-gil-state-api>
>> [image: favicon.ico] 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#python-simplified-gil-state-api>
>>  
>> <https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#python-simplified-gil-state-api>
>>
>> Try the solution described in the docs of forcing the use of the main 
>> Python interpreter by adding:
>>
>>     WSGIApplicationGroup %{GLOBAL}
>>
>> If that doesn't help you will need to work out where your code is 
>> blocking. For that try adding:
>>
>>     request-timeout=30
>>
>> option to WSGIDaemonProcess directive.
>>
>> This will cause daemon process in your case to restart after 30 seconds 
>> when it blocks and in doing that will attempt to log to error log file the 
>> stack traces of where your code was blocked.
>>
>> Graham
>>
>> On 24 Jan 2023, at 3:27 am, A <[email protected]> wrote:
>>
>> It keeps timing out and I've been trying to solve it to no avail.
>> Here my modwsgi.conf
>>
>> <VirtualHost *:80>
>>       ServerName localhost
>>       ServerAlias ----------.com *.----------.com
>>       
>>       Define project_name     ----------
>>       Define user             -------------
>>       
>>       Define project_path     /srv/http/fosware
>>       Define wsgi_path        /srv/http/fosware/fosware
>>       Define environment_path /srv/http/fosware/venv
>>       
>>       WSGIDaemonProcess ${user}-${project_name} user=${user} 
>> group=${user} processes=1 threads=1 python-eggs=/tmp/python-eggs/ 
>> python-path=${project_path}:${environment_path}/lib/python2.7/site-packages
>>       WSGIProcessGroup ${user}-${project_name}
>>
>>       WSGIScriptAlias / ${wsgi_path}/wsgi.py
>>
>>       <Directory ${project_path}>
>>         <IfVersion < 2.3 >
>>         Order allow,deny
>>         Allow from all
>>         </IfVersion>
>>         <IfVersion >= 2.3>
>>         Require all granted
>>         </IfVersion>
>>       </Directory>        
>>       
>>
>>       Alias /static ${project_path}/static
>>       <Directory ${project_path}/static>
>>              Require all granted
>>              SetHandler None
>>              FileETag none
>>              Options FollowSymLinks
>>       </Directory>
>>
>>       Alias /media ${project_path}/media
>>       <Directory ${project_path}/media>
>>              Require all granted
>>              SetHandler None
>>              FileETag none
>>              Options FollowSymLinks
>>              ErrorDocument 404 /error404
>>       </Directory>
>>
>>       ErrorLog /var/log/httpd/${user}-${project_name}-error.log
>>       LogLevel info
>>       CustomLog /var/log/httpd/${user}-${project_name}-access.log combined
>> </VirtualHost> 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/02fb2171-ca59-4053-9be3-8ff75e9cf9edn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/02fb2171-ca59-4053-9be3-8ff75e9cf9edn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/33e58e99-7f64-4dd2-bfe3-23bf2a946068n%40googlegroups.com.

Reply via email to