Re: [modwsgi] Apachectl Graceful issue

[Graham Dumpleton]

If I understand correctly then definitely look at mod_macro then as it is intended for having templates and then can then repeatedly use with different variable inputs. It doesn’t use env variables as they are really for a different purpose.GrahamOn 8 Aug 2024, at 3:25 PM, RajKumar Ambadipelli  wrote:What I am trying to do is my current virtualhost configuration is#myapp Webservice ConfigListen 9289        ServerName abc.uwareone.com        ErrorLog /var/log/abc_webservices.log        WSGIPassAuthorization On        WSGIDaemonProcess 9289abc inactivity-timeout=30 python-path=/home/admin/client-builds/abc/myapp:/home/admin/client-builds/abc/shared display-name=%{GROUP}        WSGIProcessGroup 9289abc        WSGIApplicationGroup %{GLOBAL}        WSGIScriptAlias / /home/admin/client-builds/abc/myapp/conf/wsgi.py                                 Require all granted                            ServerName xyz.uwareone.com        ErrorLog /var/log/xyz_webservices.log        WSGIPassAuthorization On        WSGIDaemonProcess 9289xyz processes=3 threads=5 inactivity-timeout=30 python-path=/home/admin/client-builds/xyz/myapp:/home/admin/client-builds/xyz/shared display-name=%{GROUP}        WSGIProcessGroup 9289xyz        WSGIApplicationGroup %{GLOBAL}        WSGIScriptAlias / /home/admin/client-builds/xyz/myapp/conf/wsgi.py                                 Require all granted                            ServerName default        ServerAlias *Like the above server name i need to server more or less like 10. The most of the configuration script is similar I just want to use some think like mod_env and use setenv variables to dynamically assign the values.RajKumarOn Thursday 8 August 2024 at 10:19:50 UTC+5:30 Graham Dumpleton wrote:Not like that.If your aim is to have a spare set of mod_wsgi daemon groups around so you can dynamically assign new sites to them without needing to do an Apache restart, there is a convoluted way one can sort of do it, but it is a bit of mucking around.Can you explain better first what you are trying to achieve so can work out whether it may even make sense or whether there is a better way.For all I know what you may want is mod_macro if just trying to cut down on duplicated configuration.mod_macro - Apache HTTP Server Version 2.4httpd.apache.orgGrahamOn 8 Aug 2024, at 2:38 PM, RajKumar Ambadipelli <arkki...@gmail.com> wrote:I have doubt,I is it possible to tell apache server during runtime i.e., dynamically to use specific wsgi daemon configuration like python-path, wsgidaemonscriptalias based on specific http_host,And also tried below configuration#myapp Webservice ConfigListen 9289SetEnv serverName abc.comSetEnv errorLogPath /var/log/abc_webservices.logSetEnv daemonName 9289abcSetEnv pythonPath /home/client-builds/abc/myapp:/home/client-builds/abc/sharedSetEnv wsgiScriptAlias /home/client-builds/abc/myapp/conf/wsgi.pySetEnv directoryPath /home/client-builds/abc/myapp/confSetEnv serverName xyz.comSetEnv errorLogPath /var/log/xyz_webservices.logSetEnv daemonName 9289xyzSetEnv pythonPath /home/client-builds/xyz/myapp:/home/client-builds/xyz/sharedSetEnv wsgiScriptAlias /home/client-builds/xyz/myapp/conf/wsgi.pySetEnv directoryPath /home/client-builds/xyz/myapp/conf        ServerName ${serverName}        ErrorLog ${errorLogPath}        WSGIPassAuthorization On        WSGIDaemonProcess ${daemonName} inactivity-timeout=30 python-path=${pythonPath} display-name=%{GROUP}        WSGIProcessGroup ${daemonName}        WSGIApplicationGroup %{GLOBAL}        WSGIScriptAlias / ${wsgiScriptAlias}                                 Require all granted                    But while iam trying to access abc.com or xyz.com it is giving me error 403 ForbiddenForbiddenYou don't have permission to access this resource.RajKumarOn Monday 5 August 2024 at 10:05:49 UTC+5:30 RajKumar Ambadipelli wrote:Understood.ThankyouRajKumarOn Monday 5 August 2024 at 09:39:47 UTC+5:30 Graham Dumpleton wrote:Memory will still be claimed by the process.I already told you to use:     inactivity-timeout=30on WSGIDaemonProcess to have the daemon processes restart after non activity for a while so memory will return to base amount for Python interpreter.GrahamOn 5 Aug 2024, at 2:06 PM, RajKumar Ambadipelli <arkki...@gmail.com> wrote:After processing request with a wsgi daemon what happens to cpu and memory footprints that is the cpu spike's that got during processing request will be gone after processing request but what about the memory footprint (ram usage) does it will remain in the cache even after completing requests if so how to gracefully remove it without disturbing the ongoing request is it even possible.RajKumarOn Thursday 1 August 2024 at 12:35:09 UTC+5:30 Graham Dumpleton wrote:The number of process/threads defined in WSGIDaemonProcess is completely independent of MPM settings and which MPM module (prefork/event/worker) is being used.Yes having 15 threads means 15 requests can be handled concurrently, but

Re: [modwsgi] Apachectl Graceful issue

[Graham Dumpleton]

If you define a daemon process group, the number of processes defined for the 
group will always be started and running.

With the way you have configured things your Python web application code is 
only loaded lazily by a process in a daemon process group when the first 
request arrives which is to be handled by that process.

Thus, prior to any request being received, the memory footprint of the 
processes should be similar to that of running an empty Python interpreter.

If your web applications are infrequently accessed and you want to minimise 
memory usage, then add to WSGIDaemonProcess the option:

inactivity-timeout=30

See 
https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIDaemonProcess.html
 for details, but basically what it means is that the process will be restarted 
when idle and will revert memory usage by the process back to the base level.

Do note however that if you Python web application takes a long time to load, 
then this may be noticeable to users if the Python web application code is 
going to have to be reloaded frequently.

As to CPU usage, the process if not handling requests will be waiting on the 
socket on which requests are listening, so it should not be using any CPU at 
that time.

There are other options to WSGIDaemonProcess you could play with to recycle the 
process periodically, but what might be appropriate really depends on your 
specific web application so I can't give concrete suggestions of what to use.

Graham

> On 31 Jul 2024, at 2:55 PM, RajKumar Ambadipelli  wrote:
> 
> What exactly I want is I want to know WSGIDaemonProcess which are ideal not 
> receiving any requests and not serving response but only declared, How does 
> this WSGIDaemonProcess effect my resources like memory and cpu.
> 
> On Wednesday 31 July 2024 at 10:22:23 UTC+5:30 RajKumar Ambadipelli wrote:
>> Creating multiple virtualhost with different mod_wsgi daemons I meant 
>> 'WSGIDaemonProcess'
>> and not using it that is it will not server and requests but only declared 
>> does this effect my resources like memory and CPU.
>> On Monday 29 July 2024 at 12:45:21 UTC+5:30 Graham Dumpleton wrote:
>>> Comes down to how much memory and CPU your machine has, plus how much 
>>> traffic the sites get. So will depend and you will just have to see how it 
>>> goes.
>>> 
>>> 
>>>> On 29 Jul 2024, at 5:12 PM, RajKumar Ambadipelli > 
>>>> wrote:
>>>> 
>>> 
>>>> Yeah it is working fine what I did was
>>>> 
>>>> step1. Unlinked existing symlink
>>>> Step2. Create new symlink
>>>> Step3. Managed permissions and shell context of files
>>>> 
>>>> Therefore no 
>>>> reload or restart is needed.
>>>> 
>>>> But I have doubt up to how many mod_wsgi daemons we can efficiently 
>>>> without any disturbance and up to what extent we can trust this deployment 
>>>> process using mod_wsgi in daemon mode for production environment.
>>>> 
>>>> Thankyou,
>>>> RajKumar
>>>> On Thursday 25 July 2024 at 13:04:18 UTC+5:30 RajKumar Ambadipelli wrote:
>>>>> Sorry that uoadmin is actually admin.
>>>>> 
>>>>> Ok I will try this one.
>>>>> 
>>>>> Thankyou,
>>>>> RajKumar
>>>>> 
>>>>> On Thursday 25 July 2024 at 12:59:13 UTC+5:30 Graham Dumpleton wrote:
>>>>>> You have two different directories which may complicate it a little, but 
>>>>>> what you can do is have something like:
>>>>>> 
>>>>>>  Listen 9002  
>>>>>>  ServerName test.myapp.com <http://test.myapp.com/> 
>>>>>>  ErrorLog /var/log/webservice_error.log 
>>>>>>  WSGIPassAuthorization On 
>>>>>>  WSGIDaemonProcess Tes9002 
>>>>>> python-path=/home/uoadmin/releases/test/students:/home/admin/releases/test/shared
>>>>>>  display-name=%{GROUP} 
>>>>>>  WSGIProcessGroup Tes9002 WSGIApplicationGroup %{GLOBAL} 
>>>>>>  WSGIScriptAlias / /home/admin/releases/test/students/conf/wsgi.py 
>>>>>>  
>>>>>>   Require all granted 
>>>>>>   
>>>>>> 
>>>>>> 
>>>>>>   
>>>>>>  ServerName dev.myapp.com <http://dev.myapp.com/> 
>>>>>>  ErrorLog /var/log/webservice_error.log 
>>>>>>  WSGIPassAuthorization On 
>>>>>>  WSGIDaemonProcess Dev9002 
>>>>>> python-path=/home/uoadmin/releas

Re: [modwsgi] Apachectl Graceful issue

[Graham Dumpleton]

Comes down to how much memory and CPU your machine has, plus how much traffic 
the sites get. So will depend and you will just have to see how it goes.

> On 29 Jul 2024, at 5:12 PM, RajKumar Ambadipelli  wrote:
> 
> Yeah it is working fine what I did was
> 
> step1. Unlinked existing symlink
> Step2. Create new symlink
> Step3. Managed permissions and shell context of files
> 
> Therefore no 
> reload or restart is needed.
> 
> But I have doubt up to how many mod_wsgi daemons we can efficiently without 
> any disturbance and up to what extent we can trust this deployment process 
> using mod_wsgi in daemon mode for production environment.
> 
> Thankyou,
> RajKumar
> On Thursday 25 July 2024 at 13:04:18 UTC+5:30 RajKumar Ambadipelli wrote:
>> Sorry that uoadmin is actually admin.
>> 
>> Ok I will try this one.
>> 
>> Thankyou,
>> RajKumar
>> 
>> On Thursday 25 July 2024 at 12:59:13 UTC+5:30 Graham Dumpleton wrote:
>>> You have two different directories which may complicate it a little, but 
>>> what you can do is have something like:
>>> 
>>>  Listen 9002  
>>>  ServerName test.myapp.com <http://test.myapp.com/> 
>>>  ErrorLog /var/log/webservice_error.log 
>>>  WSGIPassAuthorization On 
>>>  WSGIDaemonProcess Tes9002 
>>> python-path=/home/uoadmin/releases/test/students:/home/admin/releases/test/shared
>>>  display-name=%{GROUP} 
>>>  WSGIProcessGroup Tes9002 WSGIApplicationGroup %{GLOBAL} 
>>>  WSGIScriptAlias / /home/admin/releases/test/students/conf/wsgi.py 
>>>  
>>>   Require all granted 
>>>   
>>> 
>>> 
>>>   
>>>  ServerName dev.myapp.com <http://dev.myapp.com/> 
>>>  ErrorLog /var/log/webservice_error.log 
>>>  WSGIPassAuthorization On 
>>>  WSGIDaemonProcess Dev9002 
>>> python-path=/home/uoadmin/releases/dev/students:/home/admin/releases/dev/shared
>>>  display-name=%{GROUP} 
>>>  WSGIProcessGroup Dev9002 WSGIApplicationGroup %{GLOBAL} 
>>>  WSGIScriptAlias / /home/admin/releases/dev/students/conf/wsgi.py 
>>>  
>>>   Require all granted  
>>>   
>>> 
>>> 
>>> In this case /home/admin/releases/dev would actually be a symlink to the 
>>> versioned directory. 
>>> 
>>> Not sure why have separate uoadmin directory, but also have 
>>> /home/uoadmin/releases/dev as symlink to the versioned directory.
>>> 
>>> To change what is used, remove/recreate symlinks so point to the directory 
>>> for the new version.
>>> 
>>> That the wsgi.py has changed should trigger a process restart if auto 
>>> reloading is on (default).
>>> 
>>> Alternatively could disable auto reloading and manually send SIGUSR1 to 
>>> process to trigger a graceful reload after changing the symlink.
>>> 
>>> That all said, I can't remember if you might have to configure Apache to 
>>> tell it to allow following symlinks (Options FollowSymLinks). If it were 
>>> static file handling would definitely be needed, but can't remember if 
>>> would be required in this case where is WSGI application handling things.
>>> 
>>> Graham
>>> 
>>> 
>>>> On 25 Jul 2024, at 5:21 PM, RajKumar Ambadipelli > 
>>>> wrote:
>>>> 
>>> 
>>>> Ok, If I have only two virtualhosts all the time and I am going to change 
>>>> only python-path will that work with the direct signal using SIGUSR1.
>>>> 
>>>> If the above is possible then I think I have some kind of solution.
>>>> 
>>>> Thankyou,
>>>> RajKumar
>>>> 
>>>> On Thursday 25 July 2024 at 12:35:09 UTC+5:30 Graham Dumpleton wrote:
>>>>> Are you always using the same two virtual host server names and just 
>>>>> updating the version number in the paths?
>>>>> 
>>>>> 
>>>>>> On 25 Jul 2024, at 4:21 PM, RajKumar Ambadipelli > 
>>>>>> wrote:
>>>>>> 
>>>>> 
>>>>>> Yes I am adding new virtual hosts  when ever I want to release a new 
>>>>>> version of that services lets say initially my virtualhost config will 
>>>>>> be like
>>>>>> 
>>>>>> #Students Webservice Config 
>>>>>>  Listen 9002  
>>>>>>  ServerName test.myapp.com <http://test.myapp.com/> 
>>>>>>  ErrorLog /var/log/webservi

Re: [modwsgi] Apachectl Graceful issue

[Graham Dumpleton]

You have two different directories which may complicate it a little, but what 
you can do is have something like:

 Listen 9002  
 ServerName test.myapp.com 
 ErrorLog /var/log/webservice_error.log 
 WSGIPassAuthorization On 
 WSGIDaemonProcess Tes9002 
python-path=/home/uoadmin/releases/test/students:/home/admin/releases/test/shared
 display-name=%{GROUP} 
 WSGIProcessGroup Tes9002 WSGIApplicationGroup %{GLOBAL} 
 WSGIScriptAlias / /home/admin/releases/test/students/conf/wsgi.py 
 
  Require all granted 
  


  
 ServerName dev.myapp.com 
 ErrorLog /var/log/webservice_error.log 
 WSGIPassAuthorization On 
 WSGIDaemonProcess Dev9002 
python-path=/home/uoadmin/releases/dev/students:/home/admin/releases/dev/shared 
display-name=%{GROUP} 
 WSGIProcessGroup Dev9002 WSGIApplicationGroup %{GLOBAL} 
 WSGIScriptAlias / /home/admin/releases/dev/students/conf/wsgi.py 
 
  Require all granted  
  


In this case /home/admin/releases/dev would actually be a symlink to the 
versioned directory. 

Not sure why have separate uoadmin directory, but also have 
/home/uoadmin/releases/dev as symlink to the versioned directory.

To change what is used, remove/recreate symlinks so point to the directory for 
the new version.

That the wsgi.py has changed should trigger a process restart if auto reloading 
is on (default).

Alternatively could disable auto reloading and manually send SIGUSR1 to process 
to trigger a graceful reload after changing the symlink.

That all said, I can't remember if you might have to configure Apache to tell 
it to allow following symlinks (Options FollowSymLinks). If it were static file 
handling would definitely be needed, but can't remember if would be required in 
this case where is WSGI application handling things.

Graham

> On 25 Jul 2024, at 5:21 PM, RajKumar Ambadipelli  wrote:
> 
> Ok, If I have only two virtualhosts all the time and I am going to change 
> only python-path will that work with the direct signal using SIGUSR1.
> 
> If the above is possible then I think I have some kind of solution.
> 
> Thankyou,
> RajKumar
> 
> On Thursday 25 July 2024 at 12:35:09 UTC+5:30 Graham Dumpleton wrote:
>> Are you always using the same two virtual host server names and just 
>> updating the version number in the paths?
>> 
>> 
>>> On 25 Jul 2024, at 4:21 PM, RajKumar Ambadipelli > 
>>> wrote:
>>> 
>> 
>>> Yes I am adding new virtual hosts  when ever I want to release a new 
>>> version of that services lets say initially my virtualhost config will be 
>>> like
>>> 
>>> #Students Webservice Config 
>>>  Listen 9002  
>>>  ServerName test.myapp.com <http://test.myapp.com/> 
>>>  ErrorLog /var/log/webservice_error.log 
>>>  WSGIPassAuthorization On 
>>>  WSGIDaemonProcess Tes9002 
>>> python-path=/home/uoadmin/releases/1.0.0/students:/home/admin/releases/1.0.0/shared
>>>  display-name=%{GROUP} 
>>>  WSGIProcessGroup Tes9002 WSGIApplicationGroup %{GLOBAL} 
>>>  WSGIScriptAlias / /home/admin/releases/1.0.0/students/conf/wsgi.py 
>>>  
>>>   Require all granted 
>>>   
>>> 
>>> 
>>> When i want to go for new releases the down part is appended to above part 
>>> 
>>>   
>>>  ServerName dev.myapp.com <http://dev.myapp.com/> 
>>>  ErrorLog /var/log/webservice_error.log 
>>>  WSGIPassAuthorization On 
>>>  WSGIDaemonProcess Dev9002 python- 
>>> path=/home/uoadmin/releases/1.1.0/students:/home/admin/releases/1.1.0/shared
>>>  display-name=%{GROUP} 
>>>  WSGIProcessGroup Dev9002 WSGIApplicationGroup %{GLOBAL} 
>>>  WSGIScriptAlias / /home/admin/releases/1.1.0/students/conf/wsgi.py 
>>>  
>>>   Require all granted  
>>>   
>>> 
>>> 
>>> 
>>> Now I am going to have two virtualhosts with two daemons 1st is already 
>>> recognized by apache server where as second one is not yet recognized by 
>>> apache server
>>> 
>>> Thankyou,
>>> RajKumar
>>> 
>>> On Thursday 25 July 2024 at 11:40:31 UTC+5:30 Graham Dumpleton wrote:
>>>> What is the reason for doing the graceful restart? Is it because you are 
>>>> adding/removing virtual hosts, or making some other Apache config change.
>>>> 
>>>> You do not need to do a complete Apache restart if just want to force a 
>>>> daemon process to restart, you can instead send the processes a signal 
>>>> directly. From memory it is SIGUSR1 that triggers a graceful restart of 
>>>> processes, but you will need to confirm that.
>>>> 
>>>> 
>>>>> On 25 Jul 

Re: [modwsgi] Apachectl Graceful issue

[Graham Dumpleton]

Are you always using the same two virtual host server names and just updating 
the version number in the paths?

> On 25 Jul 2024, at 4:21 PM, RajKumar Ambadipelli  wrote:
> 
> Yes I am adding new virtual hosts  when ever I want to release a new version 
> of that services lets say initially my virtualhost config will be like
> 
> #Students Webservice Config 
>  Listen 9002  
>  ServerName test.myapp.com 
>  ErrorLog /var/log/webservice_error.log 
>  WSGIPassAuthorization On 
>  WSGIDaemonProcess Tes9002 
> python-path=/home/uoadmin/releases/1.0.0/students:/home/admin/releases/1.0.0/shared
>  display-name=%{GROUP} 
>  WSGIProcessGroup Tes9002 WSGIApplicationGroup %{GLOBAL} 
>  WSGIScriptAlias / /home/admin/releases/1.0.0/students/conf/wsgi.py 
>  
>   Require all granted 
>   
> 
> 
> When i want to go for new releases the down part is appended to above part 
> 
>   
>  ServerName dev.myapp.com 
>  ErrorLog /var/log/webservice_error.log 
>  WSGIPassAuthorization On 
>  WSGIDaemonProcess Dev9002 python- 
> path=/home/uoadmin/releases/1.1.0/students:/home/admin/releases/1.1.0/shared 
> display-name=%{GROUP} 
>  WSGIProcessGroup Dev9002 WSGIApplicationGroup %{GLOBAL} 
>  WSGIScriptAlias / /home/admin/releases/1.1.0/students/conf/wsgi.py 
>  
>   Require all granted  
>   
> 
> 
> 
> Now I am going to have two virtualhosts with two daemons 1st is already 
> recognized by apache server where as second one is not yet recognized by 
> apache server
> 
> Thankyou,
> RajKumar
> 
> On Thursday 25 July 2024 at 11:40:31 UTC+5:30 Graham Dumpleton wrote:
>> What is the reason for doing the graceful restart? Is it because you are 
>> adding/removing virtual hosts, or making some other Apache config change.
>> 
>> You do not need to do a complete Apache restart if just want to force a 
>> daemon process to restart, you can instead send the processes a signal 
>> directly. From memory it is SIGUSR1 that triggers a graceful restart of 
>> processes, but you will need to confirm that.
>> 
>> 
>>> On 25 Jul 2024, at 3:28 PM, RajKumar Ambadipelli > 
>>> wrote:
>>> 
>> 
>>> When i have 260 microservices those all are light weight applications using 
>>> same python interpreter and with django rest api framework, and currently 
>>> each application hosted on apache server usign mod_wsgi daemon mode and my 
>>> main problem is while making changes to one of application virtualhost 
>>> other ongoing daemons are distured as i need to reload or restart.
>>> All those 260 services very light weight each listen to http request on 
>>> unique ports.
>>> 
>>> ThankYou
>>> RajKumar
>>> 
>>> On Tuesday 23 July 2024 at 16:37:42 UTC+5:30 Graham Dumpleton wrote:
>>>> One can optimise embedded mode for better performance, but I would put a 
>>>> big caveat on that and say is only probably a good idea to tackle if you 
>>>> have the one web service.
>>>> 
>>>> Running 260 micro services in one Apache httpd instance with mod_wsgi 
>>>> sounds rather scary either way.
>>>> 
>>>> If you use mod_wsgi daemon mode where each micro service is in its own 
>>>> daemon process group (with a single process and small number of threads), 
>>>> then you might get away with it if these aren't high volume sites. That 
>>>> said, it is still a lot of managed daemon mode processes and not sure how 
>>>> well Apache will handle that, especially on restarts.
>>>> 
>>>> Running them all in embedded mode would be a bad idea if each needs a 
>>>> separate Python interpreter context because the Apache worker process 
>>>> would be huge in size. If Apache httpd was configured for prefork MPM it 
>>>> would be even worse because you would have a potentially large number of 
>>>> worker processes since all are single thread. You also run a big risk with 
>>>> micro services interfering with each other in strange ways if running in 
>>>> different sub interpreter contexts of the one process due to how Python 
>>>> imports C extensions, and process wide environment variables work. Various 
>>>> third party Python packages with C extensions will not even work in Python 
>>>> sub interpreters (eg., anything related to numpy).
>>>> 
>>>> You definitely want event or worker MPM, but even then, for 260 micro 
>>>> services, if they need separate Python interpreter context I can't really 
>>>> recommend it still because

Re: [modwsgi] Apachectl Graceful issue

[Graham Dumpleton]

What is the reason for doing the graceful restart? Is it because you are 
adding/removing virtual hosts, or making some other Apache config change.

You do not need to do a complete Apache restart if just want to force a daemon 
process to restart, you can instead send the processes a signal directly. From 
memory it is SIGUSR1 that triggers a graceful restart of processes, but you 
will need to confirm that.

> On 25 Jul 2024, at 3:28 PM, RajKumar Ambadipelli  wrote:
> 
> When i have 260 microservices those all are light weight applications using 
> same python interpreter and with django rest api framework, and currently 
> each application hosted on apache server usign mod_wsgi daemon mode and my 
> main problem is while making changes to one of application virtualhost other 
> ongoing daemons are distured as i need to reload or restart.
> All those 260 services very light weight each listen to http request on 
> unique ports.
> 
> ThankYou
> RajKumar
> 
> On Tuesday 23 July 2024 at 16:37:42 UTC+5:30 Graham Dumpleton wrote:
>> One can optimise embedded mode for better performance, but I would put a big 
>> caveat on that and say is only probably a good idea to tackle if you have 
>> the one web service.
>> 
>> Running 260 micro services in one Apache httpd instance with mod_wsgi sounds 
>> rather scary either way.
>> 
>> If you use mod_wsgi daemon mode where each micro service is in its own 
>> daemon process group (with a single process and small number of threads), 
>> then you might get away with it if these aren't high volume sites. That 
>> said, it is still a lot of managed daemon mode processes and not sure how 
>> well Apache will handle that, especially on restarts.
>> 
>> Running them all in embedded mode would be a bad idea if each needs a 
>> separate Python interpreter context because the Apache worker process would 
>> be huge in size. If Apache httpd was configured for prefork MPM it would be 
>> even worse because you would have a potentially large number of worker 
>> processes since all are single thread. You also run a big risk with micro 
>> services interfering with each other in strange ways if running in different 
>> sub interpreter contexts of the one process due to how Python imports C 
>> extensions, and process wide environment variables work. Various third party 
>> Python packages with C extensions will not even work in Python sub 
>> interpreters (eg., anything related to numpy).
>> 
>> You definitely want event or worker MPM, but even then, for 260 micro 
>> services, if they need separate Python interpreter context I can't really 
>> recommend it still because of size concerns for processes and potential 
>> cross sub interpreter interference.
>> 
>> So the question is whether when you said 260 micro services you really mean 
>> independent web applications, or whether you just mean you have 260 
>> different unique HTTP handlers as part of the one application, and thus in 
>> the same Python interpreter context.
>> 
>> When people talk about such large number of micro services, usually you 
>> would not be aiming to host them in a single Apache instance but would 
>> instead be looking at running something which can handle things at scale 
>> like Kubernetes and creating separate deployments for them in that, relying 
>> on the ingress routing Kubernetes provides to get traffic to the appropriate 
>> micro service.
>> 
>> Graham
>> 
>> 
>>> On 23 Jul 2024, at 7:13 PM, RajKumar Ambadipelli > 
>>> wrote:
>>> 
>> 
>>> mod_wsgi in embeded mode allows graceful restart,
>>> What are the potential issues that I will face if I use mod_wsgi in 
>>> embedded mode instead of daemon mode,
>>> I have to host around 260 python micro services.
>>> 
>>> I have saw your blog on 'why are you using mod_wsgi in embedded mode?' But, 
>>> I unable to understand it very well in that you mentioned if we configure 
>>> mpm settings correctly then mod_wsgi in embedded mode is better than daemon 
>>> mode but not mentioned any configurations.
>>> 
>>> Thanking you,
>>> RajKumar
>>> 
>>> On Tuesday 23 July 2024 at 13:04:50 UTC+5:30 Graham Dumpleton wrote:
>>>>> On 23 Jul 2024, at 4:09 PM, RajKumar Ambadipelli gmail.com 
>>>>> <http://gmail.com/>> wrote:
>>>>> 
>>>> 
>>>>> I am using Apache Server with mod_wsgi for hosting my python django 
>>>>> applications. Versions: Python 3.9.18 Server version: Apache/2.4.57 
>>

Re: [modwsgi] Apachectl Graceful issue

[Graham Dumpleton]

One can optimise embedded mode for better performance, but I would put a big 
caveat on that and say is only probably a good idea to tackle if you have the 
one web service.

Running 260 micro services in one Apache httpd instance with mod_wsgi sounds 
rather scary either way.

If you use mod_wsgi daemon mode where each micro service is in its own daemon 
process group (with a single process and small number of threads), then you 
might get away with it if these aren't high volume sites. That said, it is 
still a lot of managed daemon mode processes and not sure how well Apache will 
handle that, especially on restarts.

Running them all in embedded mode would be a bad idea if each needs a separate 
Python interpreter context because the Apache worker process would be huge in 
size. If Apache httpd was configured for prefork MPM it would be even worse 
because you would have a potentially large number of worker processes since all 
are single thread. You also run a big risk with micro services interfering with 
each other in strange ways if running in different sub interpreter contexts of 
the one process due to how Python imports C extensions, and process wide 
environment variables work. Various third party Python packages with C 
extensions will not even work in Python sub interpreters (eg., anything related 
to numpy).

You definitely want event or worker MPM, but even then, for 260 micro services, 
if they need separate Python interpreter context I can't really recommend it 
still because of size concerns for processes and potential cross sub 
interpreter interference.

So the question is whether when you said 260 micro services you really mean 
independent web applications, or whether you just mean you have 260 different 
unique HTTP handlers as part of the one application, and thus in the same 
Python interpreter context.

When people talk about such large number of micro services, usually you would 
not be aiming to host them in a single Apache instance but would instead be 
looking at running something which can handle things at scale like Kubernetes 
and creating separate deployments for them in that, relying on the ingress 
routing Kubernetes provides to get traffic to the appropriate micro service.

Graham

> On 23 Jul 2024, at 7:13 PM, RajKumar Ambadipelli  wrote:
> 
> mod_wsgi in embeded mode allows graceful restart,
> What are the potential issues that I will face if I use mod_wsgi in embedded 
> mode instead of daemon mode,
> I have to host around 260 python micro services.
> 
> I have saw your blog on 'why are you using mod_wsgi in embedded mode?' But, I 
> unable to understand it very well in that you mentioned if we configure mpm 
> settings correctly then mod_wsgi in embedded mode is better than daemon mode 
> but not mentioned any configurations.
> 
> Thanking you,
> RajKumar
> 
> On Tuesday 23 July 2024 at 13:04:50 UTC+5:30 Graham Dumpleton wrote:
>>> On 23 Jul 2024, at 4:09 PM, RajKumar Ambadipelli > 
>>> wrote:
>>> 
>> 
>>> I am using Apache Server with mod_wsgi for hosting my python django 
>>> applications. Versions: Python 3.9.18 Server version: Apache/2.4.57 
>>> mod-wsgi==4.7.1
>>> 
>>> One of my application virtual host configuration with two different 
>>> versions:
>>> 
>> 
>>> ...
>>> 
>> 
>>> So, When the source code is modified I can referesh the wsgi daemon using 
>>> touch /home/uoadmin/releases/1.1.0/students/conf/wsgi.py touch 
>>> /home/uoadmin/releases/1.0.0/students/conf/wsgi.py But when I added new 
>>> virtualhost to the above configuration file or else when I modify above 
>>> file the apache server unable to recognize modifications made the existing 
>>> virtualhost or newly added virtualhost until doing apachectl graceful (or) 
>>> apachectl restart (or) systemctl reload httpd but all the commands above 
>>> killing the ongoing requests forcefully directly terminating them.
>>> 
>>> How to handle above situation.
>>> 
>>> I want to know how will apache server recognize modifications to 
>>> virtualhost or newly added virtual host without reloading or restarting.
>>> 
>> 
>> It can't, Apache httpd requires you to perform a restart (reload) in order 
>> to read changes to the Apache configuration files. That is how it works.
>> 
>>> If above is not possible then is there anyway for restarting or reloading 
>>> apache server gracefully that is without terminating or killing other 
>>> ongoing requests or daemons while using apache server + mod_wsgi for 
>>> serving python with django?
>>> 
>> 
>> Unfortunately not. The way Apache httpd manages the mod_wsgi dae

Re: [modwsgi] Apachectl Graceful issue

[Graham Dumpleton]

> On 23 Jul 2024, at 4:09 PM, RajKumar Ambadipelli  wrote:
> 
> I am using Apache Server with mod_wsgi for hosting my python django 
> applications. Versions: Python 3.9.18 Server version: Apache/2.4.57 
> mod-wsgi==4.7.1
> 
> One of my application virtual host configuration with two different versions:
> 
> ...
> 
> So, When the source code is modified I can referesh the wsgi daemon using 
> touch /home/uoadmin/releases/1.1.0/students/conf/wsgi.py touch 
> /home/uoadmin/releases/1.0.0/students/conf/wsgi.py But when I added new 
> virtualhost to the above configuration file or else when I modify above file 
> the apache server unable to recognize modifications made the existing 
> virtualhost or newly added virtualhost until doing apachectl graceful (or) 
> apachectl restart (or) systemctl reload httpd but all the commands above 
> killing the ongoing requests forcefully directly terminating them.
> 
> How to handle above situation.
> 
> I want to know how will apache server recognize modifications to virtualhost 
> or newly added virtual host without reloading or restarting.
> 
It can't, Apache httpd requires you to perform a restart (reload) in order to 
read changes to the Apache configuration files. That is how it works.

> If above is not possible then is there anyway for restarting or reloading 
> apache server gracefully that is without terminating or killing other ongoing 
> requests or daemons while using apache server + mod_wsgi for serving python 
> with django?
> 
Unfortunately not. The way Apache httpd manages the mod_wsgi daemon processes 
it will force a restart of those as well and even though Apache has a concept 
of graceful restart for it's own worker child processes, it doesn't extend that 
to managed process like the mod_wsgi daemon process and always restarts them 
immediately even when it is a graceful restart. There is nothing that can be 
done about this.

The only way you could handle it if you need to be able to freely restart the 
main Apache server and have it not affect your Python web applications, is to 
run the Python web applications in distinct secondary web server processes and 
use the main Apache server to only proxy requests through to the secondary web 
servers.

For the second web servers you could use mod_wsgi-express to make things 
easier, but you could also just not use mod_wsgi for the secondary web servers 
and use gunicorn or some other standalone Python WSGI/asyncio web server.

Graham


-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/2292A86D-092F-46D1-A3CE-A9906DBC42C8%40gmail.com.

Re: [modwsgi] Module Failed when Configure With WSGI

[Graham Dumpleton]

What does your mod_wsgi configuration in Apache look like?

Is the mod_wsgi you are using definitely been compiled for Python 3.9?

This issue may be caused by one of the following:

* A permissions issue where the directory/files for the Python virtual 
environment are not all readable by the user that Apache is running your code.

* Your mod_wsgi is actually compiled for a different Python version than the 
Python virtual environment was created for.

* You are loading PHP into the same Apache instance and PHP is preloading an 
image library (which prevents PIL loading version it wants) with version which 
is incompatible with what the PIL image library is expecting. This causes 
import of PIL imaging extension to fail.

I would actually speculate it is the last one, so if you have PHP loaded into 
the same Apache instance, disable PHP so it is not loaded and see if the issue 
goes away.

Otherwise ensure you supply what your mod_wsgi configuration looks like and 
what version of Python mod_wsgi was compiled for.

> On 7 Jun 2024, at 3:29 AM, 'Satish Malviya' via modwsgi 
>  wrote:
> 
> [Thu Jun 06 22:23:44.515133 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720]   File 
> "/dbdata/webcode/ro_env/lib/python3.9/site-packages/xhtml2pdf/pisa.py", line 
> 26, in 
> [Thu Jun 06 22:23:44.515137 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720] from xhtml2pdf.document 
> import pisaDocument
> [Thu Jun 06 22:23:44.515143 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720]   File 
> "/dbdata/webcode/ro_env/lib/python3.9/site-packages/xhtml2pdf/document.py", 
> line 19, in 
> [Thu Jun 06 22:23:44.515147 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720] from reportlab.lib import 
> pdfencrypt
> [Thu Jun 06 22:23:44.515152 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720]   File 
> "/dbdata/webcode/ro_env/lib/python3.9/site-packages/reportlab/lib/pdfencrypt.py",
>  line 11, in 
> [Thu Jun 06 22:23:44.515208 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720] from reportlab.lib.utils 
> import asBytes, int2Byte, rawBytes, asNative
> [Thu Jun 06 22:23:44.515216 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720]   File 
> "/dbdata/webcode/ro_env/lib/python3.9/site-packages/reportlab/lib/utils.py", 
> line 15, in 
> [Thu Jun 06 22:23:44.515221 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720] from PIL import Image
> [Thu Jun 06 22:23:44.515226 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720]   File 
> "/dbdata/webcode/ro_env/lib/python3.9/site-packages/PIL/Image.py", line 88, 
> in 
> [Thu Jun 06 22:23:44.515230 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720] from . import _imaging as 
> core
> [Thu Jun 06 22:23:44.515241 2024] [wsgi:error] [pid 483559:tid 
> 140503462958656] [remote 106.222.212.29:21720] ImportError: cannot import 
> name '_imaging' from 'PIL' 
> (/dbdata/webcode/ro_env/lib/python3.9/site-packages/PIL/__init__.py)
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/d54d4eee-191e-405c-8a8e-b0efe9e2abcan%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/C6A44017-0499-4DBA-AAE7-510374B71290%40gmail.com.

Re: [modwsgi] mod_wsgi fails on import, using system Python not venv

[Graham Dumpleton]

Since Python is embedded inside of Apache by mod_wsgi, ie., the Python library 
is linked into the process and the CLI Python is not run/used, all virtual 
environments you use with it must be created from the same version/directory 
installation of Python as mod_wsgi was compiled for. So it is sort of 
understandable that things would break or behave strangely if your two virtual 
environments were created off different Python installations.

> On 13 May 2024, at 6:15 PM, A McBain  wrote:
> 
> On Sun, May 12, 2024 at 11:37 PM A McBain  <mailto:mcbain@gmail.com>> wrote:
>> 
>> On Sun, May 12, 2024 at 11:19 PM Graham Dumpleton
>>  wrote:
>>> 
>>> The mod_wsgi.so specified by LoadFile is what dictates version (and in what 
>>> location) of Python is being used.
>>> 
>>> Right now you are using one under your home directory. I would not be 
>>> surprised if it is compiled for the version of Python you built yourself 
>>> from source code and that is causing the problem.
>>> 
>>> Ensuring you have no virtual environments activated, run the following:
>>> 
>>> pip3 uninstall mod_wsgi
>>> 
>>> Run this multiple times until it says nothing to uninstall.
>>> 
>>> Then try rebuilding/reinstall mod_wsgi again but when you run pip install 
>>> use the --no-cache-dir option so it doesn't use old cached build.
>>> 
>>> Then update LoadFile line to use whatever location it now gets installed to 
>>> if you use a different location (eg., a dedicated virtual environment, or 
>>> system Python directory.
>>> 
>>> Ensure you stop and start Apache when changed.
>>> 
>>> Graham
>> 
>> OK I uninstalled the old one (there was only the .local copy). I ran
>> the install (with the flag) and it's now residing in the more expected
>> /usr/local/... python3.11 site-packages directory.
>> 
>> Unfortunately no dice.
>> 
>> I also did a full shutdown and boot. Nope. 😕
> 
> OK so for transparency it is working now! But heck if I know exactly why.
> 
> I know I probably caused this mess and I'm not sure how to fix it
> exactly, so I'm just going to live in my mess for the time being,
> since this is just a home dev server, and proper projects go to an
> offsite server I purposefully haven't messed up.
> 
> Also, thank you very much for helping me debug this, I really appreciate it.
> 
> For anyone else I'll go through what I found in case it helps them
> with their own weird environments.
> 
> Python versions on my server:
> 2.7.18 - the system one
> 3.11.1 - the one I compiled, only available at /usr/local/bin/python3.11
> 3.12.2 - the package/distro Python, and what is used when I do
> "python3 --version", available at /usr/bin/python3 and
> /usr/bin/python3.11
> 
> Inside the virtual environment folder of each app, which I'll just
> call Old App and New App, there's a pyvenv.cfg file. Old App appears
> to have been created with virtualenv, and New App was created with
> venv, but testing shows that doesn't matter.
> 
> Old App had different file contents in pyvenv.cfg, presumably because
> it was created prior to installing the package Python (3.11.2):
> 
> home = /usr/local/bin
> implementation = CPython
> version_info = 3.11.1.final.0
> virtualenv = 20.17.1
> include-system-site-packages = false
> base-prefix = /usr/local
> base-exec-prefix = /usr/local
> base-executable = /usr/local/bin/python3.11
> 
> New App had this in pyvenv.cfg (after I recreated it using virtualenv):
> 
> home = /usr/bin
> implementation = CPython
> version_info = 3.11.2.final.0
> virtualenv = 20.17.1+ds
> include-system-site-packages = false
> base-prefix = /usr
> base-exec-prefix = /usr
> base-executable = /usr/bin/python3
> 
> Once I changed /usr to /usr/local and python3 to python3.11 in the New
> App, the import error disappeared and left me only with logical errors
> due to mistakes in wsgi.prod.py and settings-prod.py leftover from
> debugging. Fixing those let the app start up just fine.
> 
> Something weird is going on with the Python 3.11.2, or the interaction
> between it and the Python 3.11.1, but as per above since I have the
> app working I don't have the energy right this minute to untangle
> that.
> 
> Thanks again,
> Alastair
> 
>>> On 13 May 2024, at 4:10 PM, A McBain  wrote:
>>> 
>>> On Sun, May 12, 2024 at 11:08 PM A McBain  wrote:
>>> 
>>> 
>>> 
>>> 
>>> On Sun, May 12, 2024 at 10:57 PM Graham Dumpleton 
>>>  wrote:
&g

Re: [modwsgi] mod_wsgi fails on import, using system Python not venv

[Graham Dumpleton]

The mod_wsgi.so <http://mod_wsgi.so/> specified by LoadFile is what dictates 
version (and in what location) of Python is being used.

Right now you are using one under your home directory. I would not be surprised 
if it is compiled for the version of Python you built yourself from source code 
and that is causing the problem.

Ensuring you have no virtual environments activated, run the following:

pip3 uninstall mod_wsgi

Run this multiple times until it says nothing to uninstall.

Then try rebuilding/reinstall mod_wsgi again but when you run pip install use 
the --no-cache-dir option so it doesn't use old cached build.

Then update LoadFile line to use whatever location it now gets installed to if 
you use a different location (eg., a dedicated virtual environment, or system 
Python directory.

Ensure you stop and start Apache when changed.

Graham

> On 13 May 2024, at 4:10 PM, A McBain  wrote:
> 
> On Sun, May 12, 2024 at 11:08 PM A McBain  <mailto:mcbain@gmail.com>> wrote:
>> 
>> 
>> 
>> On Sun, May 12, 2024 at 10:57 PM Graham Dumpleton 
>>  wrote:
>>> 
>>> Ensure you do a complete stop and start of Apache and not just reload or 
>>> restart in case Apache had cached a reference to a broken Python library 
>>> variant from your self compiled build.
>>> 
>>> If going to build your own Python from source code ensure you read. A bit 
>>> dated, but still relevant. Ignore that talks about Docker, still applies 
>>> for any Python build.
>>> 
>>> Installing a custom Python version into a Docker image.
>>> blog.dscpl.com.au
>>> 
>>> Also, where is LoadFile line in Apache picking up mod_wsgi.so from?
>>> 
>>> Graham
>> 
>> I don't intend to build from source again if I can help it. That was a PITA. 
>> 😄 I only did it way back since I believe at the time Python 3.11 wasn't 
>> available as a package for Devuan/Debian yet...? I honestly don't remember. 
>> Thank you for the link though if I ever do need. 🙂
>> 
>> I had been just doing "service apache2 restart" yeah, but I just tried a 
>> proper stop, then a start, and the state is the same. 😑
>> 
>> So best I can tell this is where I'm at:
>> 
>> CLI-run Python, the older site, and new site, have identical paths except 
>> for the first entry (CLI = '', apps = their app dir)
>> Both apps don't import cmath and a bunch of other modules but the CLI Python 
>> does
>> All prefixes point to the correct virtual env root
>> The old app still runs even after a full stop and start of Apache
>> 
>> I apologize for all this. I don't have any idea what's going on and I've 
>> tried everything I can think of, what you've asked / suggested, and it's 
>> still breaking my brain.
>> 
>> - Alastair
> 
> Oh, the load command. Right, so that's at 
> "/etc/apache2/mods-enabled/wsgi.load"
> 
> The contents are this:
> 
> #LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so 
> <http://mod_wsgi.so/>
> LoadModule wsgi_module
> /home/asmcbain/.local/lib/python3.11/site-packages/mod_wsgi/server/mod_wsgi-py311.cpython-311-x86_64-linux-gnu.so
>  <http://mod_wsgi-py311.cpython-311-x86_64-linux-gnu.so/>
> 
>>> On 13 May 2024, at 3:35 PM, A McBain  wrote:
>>> 
>>> On Sun, May 12, 2024 at 10:22 PM A McBain  wrote:
>>> 
>>> 
>>> On Sun, May 12, 2024 at 10:05 PM A McBain  wrote:
>>> 
>>> 
>>> On Sun, May 12, 2024 at 9:47 PM Graham Dumpleton
>>>  wrote:
>>> 
>>> 
>>> 
>>> 
>>> On 13 May 2024, at 2:33 PM, A McBain  wrote:
>>> 
>>> The old one is running on the same physical server, just with its own 
>>> Apache config and own subdomain. As to having multiple things running, 
>>> that's why I set WSGIApplicationGroup to %{SERVER} but just in case I 
>>> changed it explicitly to "enfilade.asmcbain.net" (no effect, but shouldn't 
>>> hurt anything to keep the change).
>>> 
>>> 
>>> The WSGIApplicationGroup directive sets which Python interpreter context is 
>>> used. It is distinct from the daemon process group.
>>> 
>>> You want each WSGI application instance to run in a different mod_wsgi 
>>> daemon process group if using the main Python interpreter context 
>>> (application group %{GLOBAL}).
>>> 
>>> So what you want is for each VirtualHost to use a different named mod_wsgi 
>

Re: [modwsgi] mod_wsgi fails on import, using system Python not venv

[Graham Dumpleton]

Ensure you do a complete stop and start of Apache and not just reload or 
restart in case Apache had cached a reference to a broken Python library 
variant from your self compiled build.

If going to build your own Python from source code ensure you read. A bit 
dated, but still relevant. Ignore that talks about Docker, still applies for 
any Python build.

http://blog.dscpl.com.au/2015/06/installing-custom-python-version-into.html

Also, where is LoadFile line in Apache picking up mod_wsgi.so 
<http://mod_wsgi.so/> from?

Graham

> On 13 May 2024, at 3:35 PM, A McBain  wrote:
> 
> On Sun, May 12, 2024 at 10:22 PM A McBain  <mailto:mcbain@gmail.com>> wrote:
>> 
>> On Sun, May 12, 2024 at 10:05 PM A McBain  wrote:
>>> 
>>> On Sun, May 12, 2024 at 9:47 PM Graham Dumpleton
>>>  wrote:
>>>> 
>>>> 
>>>> 
>>>> On 13 May 2024, at 2:33 PM, A McBain  wrote:
>>>> 
>>>> The old one is running on the same physical server, just with its own 
>>>> Apache config and own subdomain. As to having multiple things running, 
>>>> that's why I set WSGIApplicationGroup to %{SERVER} but just in case I 
>>>> changed it explicitly to "enfilade.asmcbain.net" (no effect, but shouldn't 
>>>> hurt anything to keep the change).
>>>> 
>>>> 
>>>> The WSGIApplicationGroup directive sets which Python interpreter context 
>>>> is used. It is distinct from the daemon process group.
>>>> 
>>>> You want each WSGI application instance to run in a different mod_wsgi 
>>>> daemon process group if using the main Python interpreter context 
>>>> (application group %{GLOBAL}).
>>>> 
>>>> So what you want is for each VirtualHost to use a different named mod_wsgi 
>>>> dameon process group.
>>>> 
>>>> 
>>>>ServerName site-1.example.com
>>>>WSGIDaemonProcess site-1  \
>>>>user=asmcbain group=asmcbain \
>>>>display-name='%{GROUP}'  \
>>>>lang='en_US.UTF-8'   \
>>>>locale='en_US.UTF-8' \
>>>>threads=5\
>>>>queue-timeout=45 \
>>>>socket-timeout=60\
>>>>connect-timeout=15   \
>>>>request-timeout=60   \
>>>>inactivity-timeout=0 \
>>>>startup-timeout=15   \
>>>>deadlock-timeout=60  \
>>>>graceful-timeout=15  \
>>>>eviction-timeout=0   \
>>>>restart-interval=0   \
>>>>shutdown-timeout=5   \
>>>>maximum-requests=0   \
>>>>python-home=/home/asmcbain/enfilade/.env \
>>>>python-path=/home/asmcbain/enfilade
>>>>WSGIProcessGroup site-1
>>>>WSGIApplicationGroup %{GLOBAL}
>>>>WSGIScriptAlias / /home/asmcbain/enfilade/atcid/wsgi.py
>>>> 
>>>> 
>>>> 
>>>>ServerName site-2.example.com
>>>>WSGIDaemonProcess site-2\
>>>>user=asmcbain group=asmcbain \
>>>>display-name='%{GROUP}'  \
>>>>lang='en_US.UTF-8'   \
>>>>locale='en_US.UTF-8' \
>>>>threads=5\
>>>>queue-timeout=45 \
>>>>socket-timeout=60\
>>>>connect-timeout=15   \
>>>>request-timeout=60   \
>>>>inactivity-timeout=0 \
>>>>startup-timeout=15   \
>>>>deadlock-timeout=60  \
>>>>graceful-timeout=15  \
>>>>   

Re: [modwsgi] mod_wsgi fails on import, using system Python not venv

[Graham Dumpleton]

> On 13 May 2024, at 2:33 PM, A McBain  wrote:
> 
> The old one is running on the same physical server, just with its own Apache 
> config and own subdomain. As to having multiple things running, that's why I 
> set WSGIApplicationGroup to %{SERVER} but just in case I changed it 
> explicitly to "enfilade.asmcbain.net <http://enfilade.asmcbain.net/>" (no 
> effect, but shouldn't hurt anything to keep the change).

The WSGIApplicationGroup directive sets which Python interpreter context is 
used. It is distinct from the daemon process group.

You want each WSGI application instance to run in a different mod_wsgi daemon 
process group if using the main Python interpreter context (application group 
%{GLOBAL}).

So what you want is for each VirtualHost to use a different named mod_wsgi 
dameon process group.


ServerName site-1.example.com
WSGIDaemonProcess site-1  \
user=asmcbain group=asmcbain \
display-name='%{GROUP}'  \
lang='en_US.UTF-8'   \
locale='en_US.UTF-8' \
threads=5\
queue-timeout=45 \
socket-timeout=60\
connect-timeout=15   \
request-timeout=60   \
inactivity-timeout=0 \
startup-timeout=15   \
deadlock-timeout=60  \
graceful-timeout=15  \
eviction-timeout=0   \
restart-interval=0   \
shutdown-timeout=5   \
maximum-requests=0   \
python-home=/home/asmcbain/enfilade/.env \
python-path=/home/asmcbain/enfilade
WSGIProcessGroup site-1
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/asmcbain/enfilade/atcid/wsgi.py



ServerName site-2.example.com
WSGIDaemonProcess site-2\
user=asmcbain group=asmcbain \
display-name='%{GROUP}'  \
lang='en_US.UTF-8'   \
locale='en_US.UTF-8' \
threads=5\
queue-timeout=45 \
socket-timeout=60\
connect-timeout=15   \
request-timeout=60   \
inactivity-timeout=0 \
startup-timeout=15   \
deadlock-timeout=60  \
graceful-timeout=15  \
eviction-timeout=0   \
restart-interval=0   \
shutdown-timeout=5   \
maximum-requests=0   \
python-home=/home/asmcbain/enfilade/.env \
python-path=/home/asmcbain/enfilade
WSGIProcessGroup site-2
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/asmcbain/enfilade/atcid/wsgi.py


So each site should have different name to WSGIDaemonProcess, with matching 
WSGIProcessGroup, and WSGIApplicationGroup should be %{GLOBAL} for both, not 
{SERVER}.

The {SERVER} value has a different meaning and best avoiding it.

So lets make sure each is running in separate daemon process groups.

BTW, also make sure that somewhere outside of all VirtualHost definitions you 
add:

WSGIRestrictEmbedded On

This will cause an error if mod_wsgi daemon process groups aren't being 
configured properly.

Graham

> 
> This is the result of the wsgi.prod.py <http://wsgi.prod.py/> printouts:
> 
> [Sun May 12 21:29:11.788518 2024] [wsgi:error] [pid 5671:tid 140047682610880] 
> sys.prefix '/home/asmcbain/enfilade/.env'
> [Sun May 12 21:29:11.788639 2024] [wsgi:error] [pid 5671:tid 140047682610880] 
> sys.path ['/home/asmcbain/enfilade', '/usr/lib/python311.zip', 
> '/usr/lib/python3.11', '/usr/lib/python3.11/lib-dynload', 
> '/home/asmcbain/enfilade/.env/lib/python3.11/site-packages']
> 
> Alastair
> 
> On Sun, May 12, 2024 at 9:24 PM Graham Dumpleton  <mailto:graham.dumple...@gmail.com>> wrote:
>> 
>> On 13 May 2024, at 2:02 PM, A McBain > <mailto:mcbain@gmail.com>> wrote:
>>> 
>>> Hi, I looked at previous messages and ot

Re: [modwsgi] mod_wsgi fails on import, using system Python not venv

[Graham Dumpleton]

On 13 May 2024, at 2:02 PM, A McBain  wrote:
> 
> Hi, I looked at previous messages and others on StackOverflow but none seem 
> to solve my issue.
> 
> I have an app I wrote working perfectly fine under Python 3.11 with mod_wsgi 
> and Apache 2.
> 
> I did a bunch of development on the app (upgraded django, new features), and 
> set up a new checkout of that on my server, with its own virtual environment 
> (using venv). It uses effectively the same config (different subdomain) in 
> Apache2 as the original older copy, but the new one fails with an import 
> error while the old one is still chugging along.

When you say "old one is still chugging along" can you confirm you are saying 
that the existing one is still running on the same server at the same time, or 
it is a completely new server you have set up.

> I double checked the instructions at 
> https://docs.djangoproject.com/en/5.0/howto/deployment/wsgi/modwsgi/
> 
> I've also re-verified the mod_wsgi I installed (via pip) matches the Python 
> version I'm using (both are Python 3.11).
> 
> I also tried:
> Removing the python-path argument
> The mod_wsgi docs suggest I don't need that if I specify python-home?
Removing python-path if it refers to site-packages directory of virtual 
environment specified to python-home is okay as path would be redundant. If 
python-path is used to tell it where your Django project is, that still needs 
to stay.
> Setting WSGIApplicationGroup to %{GLOBAL}
That is recommended, but if you are hosting multiple WSGI applications on the 
same server, they would need to be delegated to different mod_wsgi daemon 
process groups.

> Unfortunately the error didn't change at all after trying those.
> 
> I've attached the relevant apache2 config section which includes all the 
> mod_wsgi-setup (the rest is just redirects, ssl stuff, aliases, etc.)
> 
> I also attached the error from the log. It looks like it's trying to use the 
> system Python instead of the one that exists in my .env (virtual environment) 
> directory.

The virtual environment doesn't have a copy of Python stdlib files so they are 
still imported from the system Python the virtual environment was created from. 
The virtual environment effectively only has its own site-packages directory.

> I'm banging my head as to why this worked before but not now so any help is 
> much appreciated. Thank you! 🙂
> 
> Other details:
> wsgi.prod.py is the default wsgi.py, just modified to load settings.prod.py
> The server is Devuan Daedalus

At the start of your WSGI script file add:

import sys
print('sys.prefix', repr(sys.prefix))
print('sys.path', repr(sys.path))

and check Apache logs for what paths it is using.

Compare that to the working site.

Post what you learn from that.

Graham

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/7184C263-1522-4583-A98B-EC9806B0FA66%40gmail.com.

Re: [modwsgi] Multiple flask projects not running using mod_wsgi

[Graham Dumpleton]

As per the message it seems you are using a Python module that is not designed to be used in multiple sub interpreters of the same process and even has an explicit check to stop you from trying. Not really much you can do about it as Apache on Windows doesn’t support multi process.Hat is the module you are using that generates the error?On 11 May 2024, at 10:14 PM, Pooja Shastri  wrote:We have windows apache server , and we want to host parallelly 3 python-flask projects using differrent ports and same server name.Project 1 uses numpy and lxml which needs WSGIApplicationGroup %{GLOBAL} for c extensions.Project 2 and 3 does not need %{GLOBAL}%The issue is in httpd.conf file of apache if we write WSGIApplicationGroup %{GLOBAL}, then Project 1 will run for sure but from Project 2 and Project 3 only one project runs which is executed first.And the error defined is: import error: interpreter changes detected - this module can be loaded into one interpreter per processIf we remove WSGIApplicationGroup %{GLOBAL}, then Project 1 will stop as it will not execute numpy and lxml, but Project 2 and Project 3 will run.Please help with this.



-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/a273ee84-b304-45c4-9530-b6602c38b262n%40googlegroups.com.




-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/1BE1D934-87B2-49EF-B834-3916AC193D05%40gmail.com.

Re: [modwsgi] Correlation between mod_wsgi Daemon Processes and apache mpm_worker

[Graham Dumpleton]

Not sure what you are asking for at this point.

The workers talked about for the MPM are the Apache child worker processes,
which when using mod_wsgi daemon mode only serve as proxies for proxying
requests through to the mod_wsgi daemon processes. This is explained in the
videos I linked.

It would be quite normal when using mod_wsgi daemon mode that the number of
Apache child worker processes wouldn't be spun up to the max.

As I probably said before or in the videos, using prefork MPM when using
mod_wsgi daemon mode, if nothing else is running in Apache besides the
mod_wsgi application, is not a good idea. You are better off using worker
or event MPM. Only makes sense to use prefork MPM if you must run PHP in
the same Apache instance.

Can you be clearer about what you problem is?


On Wed, 27 Mar 2024 at 03:05, Manu Itutur 
wrote:

> Any chance to have some help on this ?
>
> Thanks in advance.
>
> Manu
>
> On Friday, February 9, 2024 at 1:06:11 PM UTC+1 Manu Itutur wrote:
>
>> Hello Graham,
>>
>> Thanks for your answer. Here is the full apache configuration
>>
>> 
>> Servername redacted.io
>> RewriteEngine On
>> WSGIPassAuthorization on
>> # Block access for all IPs in /etc/apache2/ipblacklist.conf
>> RewriteMap hosts-deny "txt:/etc/apache2/ipblacklist.conf"
>> RewriteCond "${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}" "!=NOT-FOUND" [OR]
>> RewriteCond "${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}" "!=NOT-FOUND"
>> RewriteRule "^" "-" [F]
>>
>> # Maintenance mode section
>>
>> # Allow Individual IP stored in /etc/apache2/maintenance.exceptions
>> addresses past maintenance page
>> RewriteMap exceptions /etc/apache2/maintenance.exceptions
>> RewriteCond ${exceptions:%{REMOTE_ADDR}} =OK
>> RewriteRule ^ - [L]
>>
>> ErrorDocument 503 /static/html/maintenance/under_construction.html
>> RewriteCond /etc/apache2/MAINTENANCE_ON -f
>> RewriteCond expr "! %{REQUEST_URI} -strmatch
>> '/static/html/maintenance/*'"
>> # Allow access for LB IPs
>> RewriteCond expr "! -R '10.108.0.0/14'"
>> RewriteRule ^ - [R=503,L]
>>
>> RewriteCond /etc/apache2/MAINTENANCE_ON !-f
>> RewriteRule ^/static/html/under_construction.html$ / [R,L]
>>
>>
>> # BLOG Conf - Test
>> ProxyPreserveHost On
>> ProxyRequests Off
>>
>> Alias /503 /home/redacted/redacted/redacted/static/html/
>> under_construction.html
>>
>> 
>> ProxyPass http://192.168.1.225/mag
>> ProxyPassReverse http://192.168.1.225/mag
>> Order allow,deny
>> Allow from all
>> ErrorDocument 503 /503
>> 
>>
>> 
>> ProxyPass http://192.168.1.186/mag/es
>> ProxyPassReverse http://192.168.1.186/mag/es
>> Order allow,deny
>> Allow from all
>> ErrorDocument 503 /503
>> 
>>
>> 
>> Order deny,allow
>> Include /etc/apache2/ipwhitelist.conf
>> Deny from all
>> ErrorDocument 503 /503
>> 
>>
>> Alias /robots.txt /home/redacted/redacted/redacted/static/robots.txt
>> Alias /.well-known/security.txt /home/redacted/redacted/redacted/static/
>> security.txt
>> Alias /favicon.ico /home/redacted/redacted/redacted/static/favicon.ico
>> Alias /static/ /home/redacted/redacted/redacted/static/
>> 
>> Options Includes FollowSymLinks MultiViews
>> Order allow,deny
>> Require all granted
>> Allow from all
>> 
>> WSGIDaemonProcess redacted python-path=/home/redacted/redacted:/home/
>> redacted/redacted/virtualenv/lib/python3.7/site-packages processes=8
>> threads=2 display-name=redacted-apache
>> WSGIScrredactedAlias / /home/redacted/redacted/redacted/conf/wsgi.prod.py
>> process-group=redacted application-group=%{GLOBAL}
>> WSGIApplicationGroup %{GLOBAL}
>> 
>> 
>> Require all granted
>> Order allow,deny
>> Allow from all
>> 
>> 
>>
>> 
>>
>> 
>> ServerName cms.redacted.io
>> Redirect 301 / https://redacted.io/
>> 
>>
>> 
>> ServerName get.redacted.io
>> Redirect 301 / https://redacted.io/
>> 
>>
>>
>> 
>>
>> Servername help.redacted.io
>> ErrorLog "/var/log/apache2/help_error_log.log"
>> CustomLog "/var/log/apache2/help_access_log.log" common
>>
>> SSLProxyEngine on
>> SSLProxyVerifyDepth 10
>> SSLProxyCheckPeerCN off
>> SSLProxyCheckPeerName off
>>
>> ProxyPreserveHost On
>> ProxyPass / https://custom.intercom.help/
>> ProxyPassReverse / https://custom.intercom.help/
>&g

Re: [modwsgi] pip can not install mod_wsgi

[Graham Dumpleton]

You do not want to be installing Python/Apache from source code on macOS.

The Apache source distributions will not even build on macOS still as far
as I know. People who package it up for distributions such as Homebrew need
to patch the sources to get it to compile.

Getting Python to install from source code on macOS can be tricky so
should also be avoided.

The only way of getting mod_wsgi to work on macOS these days that I know of
is to use Apache from Homebrew. For Python, use either Python from Homebrew
or the official Python Software Foundation binary distribution of Python.

It looks to me like you aren't using Homebrew, or if you are, it is a quite
old version of Python and Apache. Ensure you have updated Homebrew if you
are using it. The latest Python version is 3.12 yet you have 3.9, which is
a red flag, because older versions can simply stop working after OS is
updated in some cases, which may be what is occurring for you.

On Wed, 27 Mar 2024 at 02:42, Bashaar Dhoot  wrote:

>
> Hi Graham,
>
>
> I have been reading the requirements and the only thing I could think of
> is to make sure I have a complete installation of Apache, which I think I
> have.
>
> Other wise would a direct installation into python work? Or would it be
> the same problem?
>
> I am not sure which distribution of python and Apache I exactly have but
> can have a look when I’m back home.
>
> As for building them from the source code I’m not sure, would this be a
> problem? As far as I know I’ve done it through command lines on terminal.
>
> Thanks,
> Bashaar
> On Tuesday 26 March 2024 at 10:40:46 UTC Graham Dumpleton wrote:
>
>> Whose Python and Apache distributions are they?
>>
>> On macOS you shouldn't have an issue with Homebrew packages, but Fink
>> packages have been a problem in the past and I gave up using them myself a
>> very long time ago.
>>
>> Or have you built Python and Apache yourself from source code somehow?
>>
>> Graham
>>
>> On Tue, 26 Mar 2024 at 20:43, Bashaar Dhoot  wrote:
>>
>>> Hi Graham,
>>>
>>> Thanks so much for the reply. I will look into the requirements needed
>>> and have a read!
>>>
>>> This is the complete output:
>>>
>>> pip install mod_wsgi
>>> DEPRECATION: Configuring installation scheme with distutils config files
>>> is deprecated and will no longer work in the near future. If you are using
>>> a Homebrew or Linuxbrew Python, please see discussion at
>>> https://github.com/Homebrew/homebrew-core/issues/76621
>>> Collecting mod_wsgi
>>>   Using cached mod_wsgi-5.0.0.tar.gz (497 kB)
>>>   Preparing metadata (setup.py) ... done
>>> Building wheels for collected packages: mod_wsgi
>>>   Building wheel for mod_wsgi (setup.py) ... error
>>>   error: subprocess-exited-with-error
>>>
>>>   × python setup.py bdist_wheel did not run successfully.
>>>   │ exit code: 1
>>>   ╰─> [46 lines of output]
>>>   running bdist_wheel
>>>   running build
>>>   running build_py
>>>   creating build
>>>   creating build/lib.macosx-13-x86_64-cpython-39
>>>   creating build/lib.macosx-13-x86_64-cpython-39/mod_wsgi
>>>   copying src/__init__.py ->
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi
>>>   creating build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server
>>>   copying src/server/apxs_config.py ->
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server
>>>   copying src/server/__init__.py ->
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server
>>>   copying src/server/environ.py ->
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server
>>>   creating
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server/management
>>>   copying src/server/management/__init__.py ->
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server/management
>>>   creating
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server/management/commands
>>>   copying src/server/management/commands/runmodwsgi.py ->
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server/management/commands
>>>   copying src/server/management/commands/__init__.py ->
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/server/management/commands
>>>   creating build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/docs
>>>   copying docs/_build/html/__init__.py ->
>>> build/lib.macosx-13-x86_64-cpython-39/mod_wsgi/docs
>>>   creating build/lib.mac

Re: [modwsgi] pip can not install mod_wsgi

[Graham Dumpleton]

t found for option
> '-L/usr/local/opt/python@3.9
> /Frameworks/Python.framework/Versions/3.9/lib/python3.9/config'
>   ld: warning: -pie being ignored. It is only used when linking a main
> executable
>   ld: unsupported tapi file type '!tapi-tbd' in YAML file
> '/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/lib/libSystem.tbd'
> for architecture x86_64
>   clang-12: error: linker command failed with exit code 1 (use -v to
> see invocation)
>   error: command
> '/Users/bashaar/anaconda3/bin/x86_64-apple-darwin13.4.0-clang' failed with
> exit code 1
>   [end of output]
>
>   note: This error originates from a subprocess, and is likely not a
> problem with pip.
>   ERROR: Failed building wheel for mod_wsgi
>   Running setup.py clean for mod_wsgi
> Failed to build mod_wsgi
> ERROR: Could not build wheels for mod_wsgi, which is required to install
> pyproject.toml-based projects
>
> Many Thanks,
>
> Bashaar
>
> On Tuesday 26 March 2024 at 08:31:24 UTC Graham Dumpleton wrote:
>
>> You need to provide the complete output from pip, not just the last
>> message otherwise I can't tell what the problem is.
>>
>> Most likely you are either missing the Python dev package, missing a
>> compiler, or missing system Apache runtime and/or dev package.
>>
>> The requirements for what you need are mentioned in:
>>
>> * https://pypi.org/project/mod-wsgi/
>>
>> BTW, don't use "mod_wsgi-standalone" unless there is an absolute reason
>> to. Use the "mod_wsgi" package only.
>>
>> Graham
>>
>> On Tue, 26 Mar 2024 at 19:27, Bashaar Dhoot  wrote:
>>
>>> Hi,
>>>
>>> I been having a problem installing  mod_wsgi and mod_wsgi-standalone on
>>> terminal.
>>>
>>> I am getting error messages like:
>>>
>>> error: subprocess-exited-with-error
>>>
>>>   × pip subprocess to install build dependencies did not run
>>> successfully.
>>>   │ exit code: 1
>>>   ╰─> [623 lines of output]
>>>
>>> and
>>>
>>>  python setup.py egg_info did not run successfully.
>>> │ exit code: 1
>>>
>>> and
>>>
>>>  note: This error originates from a subprocess, and is likely not a
>>> problem with pip.
>>> error: subprocess-exited-with-error
>>>
>>> × pip subprocess to install build dependencies did not run successfully.
>>> │ exit code: 1
>>> ╰─> See above for output.
>>>
>>> I have looked online for solutions and really struggling to find a
>>> solution or workaround.
>>>
>>> I am running Ventura and seem to struggle downloading other packages
>>> with pip even with downgrading and upgarding it. I would really apprecite
>>> the help or someone to point me in the right direction.
>>>
>>> many thanks,
>>>
>>> Bashaar
>>>
>>> --
>>> 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 modwsgi+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/modwsgi/15ef8937-db38-4172-8d71-aeef7e21acbbn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/modwsgi/15ef8937-db38-4172-8d71-aeef7e21acbbn%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 modwsgi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/modwsgi/9ce6c5e3-1b3e-4e80-8908-0f86a3580407n%40googlegroups.com
> <https://groups.google.com/d/msgid/modwsgi/9ce6c5e3-1b3e-4e80-8908-0f86a3580407n%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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/CALRNbkD2UJ8naMoSVeC1rO%2BX0-y%3DvpWyrcQft_YH8Y-x4psujw%40mail.gmail.com.

Re: [modwsgi] pip can not install mod_wsgi

[Graham Dumpleton]

You need to provide the complete output from pip, not just the last message
otherwise I can't tell what the problem is.

Most likely you are either missing the Python dev package, missing a
compiler, or missing system Apache runtime and/or dev package.

The requirements for what you need are mentioned in:

* https://pypi.org/project/mod-wsgi/

BTW, don't use "mod_wsgi-standalone" unless there is an absolute reason to.
Use the "mod_wsgi" package only.

Graham

On Tue, 26 Mar 2024 at 19:27, Bashaar Dhoot  wrote:

> Hi,
>
> I been having a problem installing  mod_wsgi and mod_wsgi-standalone on
> terminal.
>
> I am getting error messages like:
>
> error: subprocess-exited-with-error
>
>   × pip subprocess to install build dependencies did not run successfully.
>   │ exit code: 1
>   ╰─> [623 lines of output]
>
> and
>
>  python setup.py egg_info did not run successfully.
> │ exit code: 1
>
> and
>
>  note: This error originates from a subprocess, and is likely not a
> problem with pip.
> error: subprocess-exited-with-error
>
> × pip subprocess to install build dependencies did not run successfully.
> │ exit code: 1
> ╰─> See above for output.
>
> I have looked online for solutions and really struggling to find a
> solution or workaround.
>
> I am running Ventura and seem to struggle downloading other packages with
> pip even with downgrading and upgarding it. I would really apprecite the
> help or someone to point me in the right direction.
>
> many thanks,
>
> Bashaar
>
> --
> 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 modwsgi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/modwsgi/15ef8937-db38-4172-8d71-aeef7e21acbbn%40googlegroups.com
> 
> .
>

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/CALRNbkAN17zV%2BZeTyqPHbogMkrOVdNv_zHMADz92SLGZSBtWUw%40mail.gmail.com.

Re: [modwsgi] mod_wsgi script encodings (and other issues with mod_wsgi script loading)

[Graham Dumpleton]

A WSGI script file is not a __main__ module which is how a script file
given as an argument to command line Python is treated. From memory the
code related to importing that script file as the __main__ module and all
the special treatment related to it is very convoluted and not
something that can be reused by anything else. I even recollect it being
implemented in an internal C function of CPython that can't be called by
anything else.

That was back in Python 1.X/2.X days though. The question thus is whether
Python 3.X has refactored the code for processing the script file as the
__main__ module out into a separate pure Python code module. If that has
been done, and one can dictate a different name for the module besides
__main__ (which cannot be used in mod_wsgi since one could technically have
multiple loaded WSGI script files in the same interpreter context which
need to be named differently), then maybe it could be reused. This also
depends though on whether module reload for embedded mode of mod_wsgi can
still be handled.

So there are quite a lot of technical problems that would need to be solved
first.

If you have the time and can at least identify for me where in the CPython
code (or Python stdlib) the importing of __main__ Python script file is
handled with the behaviour you need, that would give me a head start to
work out whether it is practical. A starting point may be the run.py
module, but not sure these days after all the rewrites of the Python module
system over time where it is even handled.

So it may be possible now that mod_wsgi is only supporting Python 3, it
definitely wouldn't have been possible when was supporting both Python 2
and 3 though, as pretty sure how it was done in Python 2 meant code wasn't
reusable (or that could have been Python 1.X).

On Fri, 22 Mar 2024 at 13:36, Lucas Thode  wrote:

> The problem with your statement that "As to the initial WSGI script file,
> it is not a module import and so any special language encoding definition
> in a magic header of the file is ignored and it should just use whatever
> the Python lang/locale is set to." is that the CPython interpreter itself
> does not ignore magic headers and zipapp functionality when passed a script
> file on the command line.  Indeed, `python3 myapp.pyz`, where myapp.pyz is
> a valid Python zipapp, will run the Python code in the zipapp's
> __main__.py.  Should I file a bug against mod_wsgi regarding its lack of
> support for what is normal Python functionality in every other context (not
> just imported modules)?
>
> On Thursday, March 21, 2024 at 9:00:35 PM UTC-5 Graham Dumpleton wrote:
>
> Depends a little bit on whether you are using embedded mode or daemon mode
> of mod_wsgi, or whether using mod_wsgi-express.
>
> The Python embedded in Apache when not using mod_wsgi-express should by
> default inherit the system default locale. This is often the C or POSIX
> locale from memory and not any variant of UTF-8 because Linux distros don't
> necessarily do sane things, although this may actually have changed.
>
> What is calculated for language/local for specific HTTP requests to Apache
> based on Apache's rules makes no difference.
>
> If you are using daemon mode of mod_wsgi you can use the lang/locale
> option to the WSGIDaemonProcess directive to explicitly set it for those
> processes.
>
>
> https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIDaemonProcess.html#lang
>
> https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIDaemonProcess.html#locale
>
> I can't remember if there is a way of overriding it for embedded mode
> easily besides setting it in systemd or other startup files which startup
> Apache, I don't think so, so it is governed by what Apache process inherits
> from the system. You can possibly use Python functions to change it after
> the process started, but that may be too late for stuff which is already
> imported.
>
> If you are using mod_wsgi-express, it tries to set things itself to a sane
> value if not set by the --locale command line option.
>
> Bit of a description about it in:
>
>
> https://github.com/GrahamDumpleton/mod_wsgi/blob/f54eadd6da8e3da0faccd497d4165de435b97242/docs/release-notes/version-4.4.3.rst#features-changed
>
>
>
>
>
> *  The behaviour of the --locale option to mod_wsgi-express has changed.
> Previously if this option was not defined, then both of the locales
> en_US.UTF-8 and C.UTF-8 have at times been hardwired as the default locale.
> These locales are though not always present. As a consequence, a new
> algorithm is now used.  If the --locale option is supplied, the argument
> will be used as the locale. If no argument is supplied, the default locale
> for the executing mod_wsgi-express process wi

Re: [modwsgi] mod_wsgi script encodings (and other issues with mod_wsgi script loading)

[Graham Dumpleton]

Depends a little bit on whether you are using embedded mode or daemon mode
of mod_wsgi, or whether using mod_wsgi-express.

The Python embedded in Apache when not using mod_wsgi-express should by
default inherit the system default locale. This is often the C or POSIX
locale from memory and not any variant of UTF-8 because Linux distros don't
necessarily do sane things, although this may actually have changed.

What is calculated for language/local for specific HTTP requests to Apache
based on Apache's rules makes no difference.

If you are using daemon mode of mod_wsgi you can use the lang/locale option
to the WSGIDaemonProcess directive to explicitly set it for those processes.

https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIDaemonProcess.html#lang
https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIDaemonProcess.html#locale

I can't remember if there is a way of overriding it for embedded mode
easily besides setting it in systemd or other startup files which startup
Apache, I don't think so, so it is governed by what Apache process inherits
from the system. You can possibly use Python functions to change it after
the process started, but that may be too late for stuff which is already
imported.

If you are using mod_wsgi-express, it tries to set things itself to a sane
value if not set by the --locale command line option.

Bit of a description about it in:

https://github.com/GrahamDumpleton/mod_wsgi/blob/f54eadd6da8e3da0faccd497d4165de435b97242/docs/release-notes/version-4.4.3.rst#features-changed





*  The behaviour of the --locale option to mod_wsgi-express has changed.
Previously if this option was not defined, then both of the locales
en_US.UTF-8 and C.UTF-8 have at times been hardwired as the default locale.
These locales are though not always present. As a consequence, a new
algorithm is now used.  If the --locale option is supplied, the argument
will be used as the locale. If no argument is supplied, the default locale
for the executing mod_wsgi-express process will be used. If that however is
C or POSIX, then an attempt will be made to use either the en_US.UTF-8 or
C.UTF-8 locales and if that is not possible only then fallback to the
default locale of the mod_wsgi-express process.  In other words, unless you
override the default language locale, an attempt is made to use an English
language locale with UTF-8 encoding.*

So the wisest thing to do if you have a special requirement is to set
--locale option.

If you force mod_wsgi-express into embedded mode though, it possibly just
inherits whatever parent shell is using again, I can't remember if
mod_wsgi-express tries to set it in the parent process as well so inherited
in the child process.

As to the initial WSGI script file, it is not a module import and so any
special language encoding definition in a magic header of the file is
ignored and it should just use whatever the Python lang/locale is set to.

If you need such a thing to be honoured then don't put your real code in
the WSGI script file and instead hold your project code in a distinct
Python package structure and import modules from it in the WSGI script file.

Not sure if this answers your question or not. My memory is very murky
about some of this stuff, especially what happens in embedded mode.

Graham

On Fri, 22 Mar 2024 at 12:31, Lucas Thode  wrote:

> What determines which encoding mod_wsgi uses when it reads WSGI scripts:
> Apache's configured locale (which for me is en_us.UTF8), or something
> else?  (I ask about this because mod_wsgi appears to do low-level manual
> hackery when reading wsgi script files instead of going through importlib
> or runpy, which means that it can't handle a zipapp or even something that
> uses a PEP 263 magic comment to convey encoding information, the latter
> making it impossible to "wrap" a zipapp with a loader shim even unless
> something else gives.)
>
> Minimized example (works when you run it using python3 breaks.py, breaks
> with the errors below if you try to load it using `mod_wsgi-express
> start-server breaks.py` using a mod_wsgi-express installed into a venv with
> pip install), note that you will have to save breaks.py as
> latin1/iso-8859-1 to cause this to break):
>
> $ cat breaks.py
> # coding: latin1
> import sys
> from wsgiref.simple_server import make_server
>
> def application(environ, start_response):
> start_response('200 OK', [('Content-Type', 'text/plain')])
> message = 'It works!\n'
> version = 'Python v' + sys.version.split()[0] + '\n'
> response = '\n'.join([message, version])
> return [response.encode()]
>
> def main():
> with make_server('', 8100, application) as httpd:
> httpd.serve_forever()
>
> blow_up_unicode = 'â(¡' # \xe2\x28\xa1
>
> if __name__ == '__main__':
> main()
>
> Errors it generates when run under mod_wsgi-express:
> [Thu Mar 21 20:12:56.942439 2024] [wsgi:error] [pid 3288289:tid
> 140356515776384]
>  mod_wsgi (pid=3288289):

Re: [modwsgi] Django site doesn't run after machine rebuild using 4.9.0

[Graham Dumpleton]

Keep in mind that if you have a WSGI file in at the location:

/data/www/wikidataDiscovery/wikidataDiscovery/wsgi.py

it is not sufficient that the file
/data/www/wikidataDiscovery/wikidataDiscovery/wsgi.py be readable. It is
also necessary that all the parent directories down to that location are
readable/accessible to the user that Apache runs as.

So check the permissions on:

/data/
/data/www/
/data/www/wikidataDiscovery/
/data/www/wikidataDiscovery/wikidataDiscovery/

as well.

BTW, if you only have one application delegated to a daemon process group,
it is best practice to force the use of the main interpreter context of
that Python interpreter instance.

So add:

WSGIApplicationGroup %{GLOBAL}

This has nothing to do with the problem, but always a good idea as not all
third party Python packages will work in sub interpreters.

Graham

On Sun, 3 Mar 2024 at 08:59, Andre Hulet  wrote:

> I run one of my Django sites on my local machine for testing. I recently
> had to rebuild the machine, and now my site doesn't run (403-you don't have
> permission to access this resource) even though .conf file settings and
> file system permissions appear identical. I have a hello world wsgi app
> that runs fine so long as my Django site is not enabled, in which case the
> Hello World app returns 404. The only thing different in my setup that I
> can think of is that I installed mod wsgi 4.9.0 via apt rather than
> compiling and installing 5.0.
>
> Ubuntu: 22.04
> Apache: 2.4.52
> wsgi: 4.9.0
>
> I realize this might be an OS permissions issue relating to the rebuild
> (though I don't see how), but I'm new enough to wsgi to be unsure about my
> conf file. Here it is. Any suggestions are greatly appreciated.
>
> ```
> WSGIScriptAlias /discover
> /data/www/wikidataDiscovery/wikidataDiscovery/wsgi.py
> WSGIDaemonProcess wikiframe.local
> python-home=/data/www/wikidataDiscovery/wd_venv/
>  python-path=/data/www/wikidataDiscovery/ processes=1 threads=10
> display-name=%{GROUP}
> WSGIProcessGroup wikiframe.local
>
> ServerName wikiframe.local
> ServerAdmin xxx...@yyy.com
> DocumentRoot /data/www/
>
> Alias /static /data/www/wd_static
> Alias /downloads /data/www/wikidataDiscovery/downloads
>
> 
>   
> Require all granted
>   
>
>  
> Require all granted
>   
>
>
> ErrorLog ${APACHE_LOG_DIR}/wikiframe-error.log
>   CustomLog ${APACHE_LOG_DIR}/wikiframe-access.log combined
>
>   
> Options FollowSymLinks IncludesNOEXEC
> AllowOverride All
> Require all granted
>   
>
>   
> AllowOverride All
> Require all granted
>   
>
> 
> 
>   Require all granted
> 
>   
>
> 
> ```
>
> --
> 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 modwsgi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/modwsgi/b5acf1c3-9f6c-4855-b6e4-19efa5cb78een%40googlegroups.com
> 
> .
>

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/CALRNbkCfjJY1PSC%3DqQr0yFOvNJ5YP1Cma2z57x%3DfqD%3D0YU8SHQ%40mail.gmail.com.

Re: [modwsgi] print() output not appearing in apache error.log with Python 3

[Graham Dumpleton]

Have you tried just a WSGI hello world with print() statements in it to
make sure nothing about any framework used is interfering.

import sys

def application(environ, start_response):
status = '200 OK'
output = b'Hello World!'

print("Hi there!")

print("Send to stdout explicitly", file=sys.stdout)

print("Send to stderr explicitly", file=sys.stderr)

print("stdout", type(sys.stdout))

print("stderr", type(sys.stderr))

response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)

return [output]




On Fri, 1 Mar 2024 at 07:50, YKdvd  wrote:

> I've got a Flask wsgi app, where there are print statements in the
> myapp.wsgi, which take advantage of the "send unhandled print stuff out
> through the apache error log".  This was working fine with Python
> 2.7/Ubuntu 16.04, and the output appeared in the apache error.log as
> expected.  But after conversion to Python 3.9/Ubuntu 22.04 (mod_wsgi 4.9.x,
> Flask 2.3.x, I think), the output of print() statements doesn't seem to get
> to the apache log anymore.  Later on in the request handling of the app, I
> have Python logging established (normal stdout, I think), and that output
> does get to the error log, but print() statements still don't.
>
> I assume there is some sort of change in how Python 3 is handling
> stdout/stderr, or how Flask or mod_wsgi interact with that, and the print()
> text never gets out, or goes to a bitbucket, or something, but I can't
> figure out why or how I might fix it.  I've tried a couple things to monkey
> with Python's stdout/stderr before the first print statement, but didn't
> have any luck.  I could go through and replace some of the old print
> statements with Python logging calls, but I'd like to figure this out and
> fix it if possible, if anyone has any ideas or pointers as to what might be
> happening?
>
> --
> 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 modwsgi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/modwsgi/023ebed2-57ac-4a17-a9d3-567660a76aa4n%40googlegroups.com
> 
> .
>

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/CALRNbkBtfCen-6XfN%3DLqWqFSUdXVu-GPTdBfUSsCUTZAjL4mJg%40mail.gmail.com.

Re: [modwsgi] How to tell which version of mod_wsgi Apache is using?

[Graham Dumpleton]

Sorry, read too quickly.

The Apache error logs when it starts up should show the mod_wsgi version.

If a new enough mod_wsgi version you can also import mod_wsgi module and print 
out version.

https://modwsgi.readthedocs.io/en/master/user-guides/assorted-tips-and-tricks.html
Know whether mod_wsgi module is from a system package or self installed is a 
but more difficult.

Graham


> On 5 Feb 2024, at 11:04 am, Olof S  wrote:
> 
> If I understand that documentation correctly, that tells me about the python 
> version. I'm instead after seeing which version of mod_wsgi I'm using. What 
> am I missing?
> 
> On Sun, Feb 4, 2024, 20:24 Graham Dumpleton  <mailto:graham.dumple...@gmail.com>> wrote:
>> See documentation at:
>> 
>> Checking Your Installation — mod_wsgi 5.0.0 documentation
>> modwsgi.readthedocs.io
>> 
>>  
>> <https://modwsgi.readthedocs.io/en/master/user-guides/checking-your-installation.html#python-installation-in-use>Checking
>>  Your Installation — mod_wsgi 5.0.0 documentation 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/checking-your-installation.html#python-installation-in-use>
>> modwsgi.readthedocs.io 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/checking-your-installation.html#python-installation-in-use>
>>   
>> <https://modwsgi.readthedocs.io/en/master/user-guides/checking-your-installation.html#python-installation-in-use>
>> 
>>> On 4 Feb 2024, at 10:59 pm, Olof S >> <mailto:olofde...@gmail.com>> wrote:
>>> 
>>> Thank you so much for mod_wsgi!
>>> 
>>> How can I tell which version of mod_wsgi is in use? Someone else set up the 
>>> server ages ago, and I don't know if Apache is using the version of 
>>> mod_wsgi from the system package manager, or if it's using some version 
>>> built from source, and if so which. Is there a way to find this out?
>>> 
>>> The only copy of mod_wsgi.so I can find is
>>> /usr/lib/apache2/modules/mod_wsgi.so,
>>> which is symlinked to mod_wsgi.so-3.9.
>>> 
>>> On the other hand, dpkg -l shows that libapache2-mod-wsgi-py3 4.7.1-3 is 
>>> installed on the system. Can I somehow tell if this is what Apache is 
>>> actually using?
>>> 
>>> Thanks!
>>> 
>>> -- 
>>> 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 modwsgi+unsubscr...@googlegroups.com 
>>> <mailto:modwsgi+unsubscr...@googlegroups.com>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/modwsgi/9968691a-cc2c-4252-a007-9f35e0ba438en%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/modwsgi/9968691a-cc2c-4252-a007-9f35e0ba438en%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> 
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "modwsgi" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/modwsgi/EsspI-134Lo/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> modwsgi+unsubscr...@googlegroups.com 
>> <mailto:modwsgi+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/21FD5A44-B168-4E14-AC67-277A043FE6C2%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/21FD5A44-B168-4E14-AC67-277A043FE6C2%40gmail.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 modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/CALEkGdVtt1mfYszfFDdL9H0sYAFaLG7OH_ra2_qRvR%2B-uznmFQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/modwsgi/CALEkGdVtt1mfYszfFDdL9H0sYAFaLG7OH_ra2_qRvR%2B-uznmFQ%40mail.gmail.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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/35E4E218-5C2E-496C-87EA-8C52080B12A9%40gmail.com.

Re: [modwsgi] How to tell which version of mod_wsgi Apache is using?

[Graham Dumpleton]

See documentation at:

https://modwsgi.readthedocs.io/en/master/user-guides/checking-your-installation.html#python-installation-in-use

> On 4 Feb 2024, at 10:59 pm, Olof S  wrote:
> 
> Thank you so much for mod_wsgi!
> 
> How can I tell which version of mod_wsgi is in use? Someone else set up the 
> server ages ago, and I don't know if Apache is using the version of mod_wsgi 
> from the system package manager, or if it's using some version built from 
> source, and if so which. Is there a way to find this out?
> 
> The only copy of mod_wsgi.so I can find is
> /usr/lib/apache2/modules/mod_wsgi.so,
> which is symlinked to mod_wsgi.so-3.9.
> 
> On the other hand, dpkg -l shows that libapache2-mod-wsgi-py3 4.7.1-3 is 
> installed on the system. Can I somehow tell if this is what Apache is 
> actually using?
> 
> Thanks!
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/9968691a-cc2c-4252-a007-9f35e0ba438en%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/21FD5A44-B168-4E14-AC67-277A043FE6C2%40gmail.com.

Re: [modwsgi] running 5.0.0 on Rocky Linux 9

[Graham Dumpleton]

Looks about normal for RH based Linux variants.

The compiler development tool suite may well have got installed automatically 
when installed python3-devel as should have been a dependency on it.

> On 26 Jan 2024, at 6:41 am, Steve Grubb  wrote:
> 
> Today I was able to stand up apache with mod_wsgi  on Rocky Linux 9  
> python3.9 is native ... so the basic steps were:
> 
>   sudo dnf update
>   sudo dnf install httpd
>   sudo dnf install httpd-devel
>   sudo dnf groupinstall development(not sure if necessary)
>   sudo dnf install python3-devel  (otherwise you get   not 
> found)
>   
> Then dd the mod_wsgi  ./configure   and  make  steps  (not sudo; not in any 
> venv since 3.9 is native).   Then if all's well:   sudo make install
> 
> Also in  /etc/httpd/conf.modules.d  create a file named 10-wsgi.conf and put 
> this statement in it:
> LoadModule wsgi_module modules/mod_wsgi.so
> 
> Then the usual apache config and /var/www/wsgi-scripts and wsgirun things, 
> and (re)start httpd
> 
> steve
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/23d7e3e9-d4a4-487a-b3f4-5326d27ddbc3n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/C3CD5248-2C51-4F97-8EC3-FFE325CAF189%40gmail.com.

Re: [modwsgi] I am unable to install mod_wsgi in windows 11

[Graham Dumpleton]

You can use any recent Python 3.X version. Right now it is picking some Python 
3.7 installation you have and not Python 3.11 as you expected. All I can tell 
you is that you have probably installed multiple versions of Python at 
different times but in some cases have installed it just for your user. If you 
are going to run Apache as a system service, you should install Python for all 
users, not just your own user, or it may not find the Python installation 
properly when Apache is run. So all I can suggest if you want to ensure you are 
using Python 3.11 is uninstall the Python 3.7 installed against just your user, 
and then (re)install Python 3.11 for all users.

As to MS C++ version, it appears that for Python 3.5 - 3.12+, you need to use 
MS C++ version 14.x. See:

https://wiki.python.org/moin/WindowsCompilers

I would suggest attempting to reinstall MS C++ to resolve the missing header 
file problem I already pointed out, along with all other required MS build 
tools.

For same issue as others have had, see:

https://stackoverflow.com/questions/58135999/cant-build-mod-wsgi-on-windows-10-cannot-open-include-file-ws2tcpip-h

Take note how they say you must have all of:

Visual Studio Build Tools Main Components
SDK for Windows 10 (10.0.18362.0) since I'm using Windows 10
MSVC 140 - C++ VS 2015 (v.14.00)
Graham

> On 20 Jan 2024, at 5:43 pm, Ananth Mandli  wrote:
> 
> please help me which version i have to use
> 
> 
> On Sat, 20 Jan 2024 at 11:09, Ananth Mandli  <mailto:mandliana...@gmail.com>> wrote:
>> I don't know What's wrong i did
>> 
>> 
>> Collecting mod_wsgi==4.5.24
>>   Using cached mod_wsgi-4.5.24.tar.gz (2.6 MB)
>>   Preparing metadata (setup.py) ... done
>> Building wheels for collected packages: mod_wsgi
>>   Building wheel for mod_wsgi (setup.py) ... error
>>   error: subprocess-exited-with-error
>> 
>>   × python setup.py bdist_wheel did not run successfully.
>>   │ exit code: 1
>>   ╰─> [375 lines of output]
>> 
>> On Sat, 20 Jan 2024 at 11:07, Ananth Mandli > <mailto:mandliana...@gmail.com>> wrote:
>>> I am using 
>>> ==> Python 3.11.1
>>> ==>Apache24
>>> ==>Microsoft visual c++ 2015-2022 redistributable
>>> 
>>> On Sat, 20 Jan 2024 at 01:29, Graham Dumpleton >> <mailto:graham.dumple...@gmail.com>> wrote:
>>>> This error generally indicates you have the wrong version or a badly 
>>>> installed version of the Microsoft Visual Studio build tools.
>>>> 
>>>> Try reinstalling Visual Studio Build Tools, making sure it is the correct 
>>>> version for the version of Python you are using. Since you are using an 
>>>> older version of Python, it may be an older version of the Visual Studio 
>>>> Build Tools that is required. Better still, upgrade you Python version to 
>>>> the latest.
>>>> 
>>>>> On 19 Jan 2024, at 11:20 pm, Ananth Mandli >>>> <mailto:mandliana...@gmail.com>> wrote:
>>>>> 
>>>>>  Building wheel for mod_wsgi (setup.py) ... error
>>>>>   error: subprocess-exited-with-error
>>>>> 
>>>>>   × python setup.py bdist_wheel did not run successfully.
>>>>>   │ exit code: 1
>>>>>   ╰─> [375 lines of output]
>>>>> 
>>>>> 
>>>>> 
>>>>>   creating build\temp.win32-cpython-37\Release\src\server
>>>>>   "C:\Program Files (x86)\Microsoft Visual 
>>>>> Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\cl.exe" 
>>>>> /c /nologo /O2 /W3 /GL /DNDEBUG /MD -ID:\xampp\apache/include 
>>>>> -Ic:\users\91915\appdata\local\programs\python\python37-32\include 
>>>>> -Ic:\users\91915\appdata\local\programs\python\python37-32\Include 
>>>>> "-IC:\Program Files (x86)\Microsoft Visual 
>>>>> Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\include" "-IC:\Program 
>>>>> Files (x86)\Microsoft Visual 
>>>>> Studio\2022\BuildTools\VC\Auxiliary\VS\include" /Tcsrc/server\mod_wsgi.c 
>>>>> /Fobuild\temp.win32-cpython-37\Release\src/server\mod_wsgi.obj
>>>>> 
>>>>>   mod_wsgi.c
>>>>>   
>>>>> C:\Users\91915\AppData\Local\Temp\pip-install-8p707y44\mod-wsgi_03760927e1fe4d73a104f496ddd3278c\src\server\wsgi_apache.h(39):
>>>>>  fatal error C1083: Cannot open include file: 'ws2tcpip.h': No such file 
>>>>> or directory
>>>>> 
>>>>> 
>>>>>   

Re: [modwsgi] I am unable to install mod_wsgi in windows 11

[Graham Dumpleton]

There is something broken about your Python installation if you think you are 
using Python 3.11.

The compiler output shows:

-Ic:\users\91915\appdata\local\programs\python\python37-32\include 
-Ic:\users\91915\appdata\local\programs\python\python37-32\Include

As you can see it is trying to use Python 3.7.

Uninstall the Python 3.7 version and reinstall Python 3.11, ensuring that it is 
installed for all users.

Graham

> On 20 Jan 2024, at 4:37 pm, Ananth Mandli  wrote:
> 
> I am using 
> ==> Python 3.11.1
> ==>Apache24
> ==>Microsoft visual c++ 2015-2022 redistributable
> 
> On Sat, 20 Jan 2024 at 01:29, Graham Dumpleton  <mailto:graham.dumple...@gmail.com>> wrote:
>> This error generally indicates you have the wrong version or a badly 
>> installed version of the Microsoft Visual Studio build tools.
>> 
>> Try reinstalling Visual Studio Build Tools, making sure it is the correct 
>> version for the version of Python you are using. Since you are using an 
>> older version of Python, it may be an older version of the Visual Studio 
>> Build Tools that is required. Better still, upgrade you Python version to 
>> the latest.
>> 
>>> On 19 Jan 2024, at 11:20 pm, Ananth Mandli >> <mailto:mandliana...@gmail.com>> wrote:
>>> 
>>>  Building wheel for mod_wsgi (setup.py) ... error
>>>   error: subprocess-exited-with-error
>>> 
>>>   × python setup.py bdist_wheel did not run successfully.
>>>   │ exit code: 1
>>>   ╰─> [375 lines of output]
>>> 
>>> 
>>> 
>>>   creating build\temp.win32-cpython-37\Release\src\server
>>>   "C:\Program Files (x86)\Microsoft Visual 
>>> Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\cl.exe" /c 
>>> /nologo /O2 /W3 /GL /DNDEBUG /MD -ID:\xampp\apache/include 
>>> -Ic:\users\91915\appdata\local\programs\python\python37-32\include 
>>> -Ic:\users\91915\appdata\local\programs\python\python37-32\Include 
>>> "-IC:\Program Files (x86)\Microsoft Visual 
>>> Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\include" "-IC:\Program 
>>> Files (x86)\Microsoft Visual 
>>> Studio\2022\BuildTools\VC\Auxiliary\VS\include" /Tcsrc/server\mod_wsgi.c 
>>> /Fobuild\temp.win32-cpython-37\Release\src/server\mod_wsgi.obj
>>> 
>>>   mod_wsgi.c
>>>   
>>> C:\Users\91915\AppData\Local\Temp\pip-install-8p707y44\mod-wsgi_03760927e1fe4d73a104f496ddd3278c\src\server\wsgi_apache.h(39):
>>>  fatal error C1083: Cannot open include file: 'ws2tcpip.h': No such file or 
>>> directory
>>> 
>>> 
>>>   error: command 'C:\\Program Files (x86)\\Microsoft Visual 
>>> Studio\\2022\\BuildTools\\VC\\Tools\\MSVC\\14.38.33130\\bin\\HostX86\\x86\\cl.exe'
>>>  failed with exit code 2
>>>   [end of output]
>>> 
>>> -- 
>>> 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 modwsgi+unsubscr...@googlegroups.com 
>>> <mailto:modwsgi+unsubscr...@googlegroups.com>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/modwsgi/a0e4c5a3-20c4-4c3b-8d63-d847796250b7n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/modwsgi/a0e4c5a3-20c4-4c3b-8d63-d847796250b7n%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 modwsgi+unsubscr...@googlegroups.com 
>> <mailto:modwsgi+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/2514DFA1-2CAE-435E-8325-939097C0BB47%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/2514DFA1-2CAE-435E-8325-939097C0BB47%40gmail.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 modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/CAH3LPqmjFV6sg6kSHHJqqWZ0rparapAVn-dEgJdj%3DJvz6qjUTA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/modwsgi/CAH3LPqmjFV6sg6kSHHJqqWZ0rparapAVn-dEgJdj%3DJvz6qjUTA%40mail.gmail.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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/63F42868-4C20-4BBE-B717-DC5E85510393%40gmail.com.

Re: [modwsgi] I am unable to install mod_wsgi in windows 11

[Graham Dumpleton]

This error generally indicates you have the wrong version or a badly installed 
version of the Microsoft Visual Studio build tools.

Try reinstalling Visual Studio Build Tools, making sure it is the correct 
version for the version of Python you are using. Since you are using an older 
version of Python, it may be an older version of the Visual Studio Build Tools 
that is required. Better still, upgrade you Python version to the latest.

> On 19 Jan 2024, at 11:20 pm, Ananth Mandli  wrote:
> 
>  Building wheel for mod_wsgi (setup.py) ... error
>   error: subprocess-exited-with-error
> 
>   × python setup.py bdist_wheel did not run successfully.
>   │ exit code: 1
>   ╰─> [375 lines of output]
> 
> 
> 
>   creating build\temp.win32-cpython-37\Release\src\server
>   "C:\Program Files (x86)\Microsoft Visual 
> Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\cl.exe" /c 
> /nologo /O2 /W3 /GL /DNDEBUG /MD -ID:\xampp\apache/include 
> -Ic:\users\91915\appdata\local\programs\python\python37-32\include 
> -Ic:\users\91915\appdata\local\programs\python\python37-32\Include 
> "-IC:\Program Files (x86)\Microsoft Visual 
> Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\include" "-IC:\Program Files 
> (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\VS\include" 
> /Tcsrc/server\mod_wsgi.c 
> /Fobuild\temp.win32-cpython-37\Release\src/server\mod_wsgi.obj
> 
>   mod_wsgi.c
>   
> C:\Users\91915\AppData\Local\Temp\pip-install-8p707y44\mod-wsgi_03760927e1fe4d73a104f496ddd3278c\src\server\wsgi_apache.h(39):
>  fatal error C1083: Cannot open include file: 'ws2tcpip.h': No such file or 
> directory
> 
> 
>   error: command 'C:\\Program Files (x86)\\Microsoft Visual 
> Studio\\2022\\BuildTools\\VC\\Tools\\MSVC\\14.38.33130\\bin\\HostX86\\x86\\cl.exe'
>  failed with exit code 2
>   [end of output]
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/a0e4c5a3-20c4-4c3b-8d63-d847796250b7n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/2514DFA1-2CAE-435E-8325-939097C0BB47%40gmail.com.

Re: [modwsgi] Using write with large amounts of data causing disconnects

[Graham Dumpleton]

If using the file_wrapper feature, make sure you also add:

WSGIEnableSendfile On

to mod_wsgi configuration as not on by default:

https://modwsgi.readthedocs.io/en/master/release-notes/version-4.1.0.html#features-changed

The file_wrapper mechanism would still have worked, but to use kernel sendfile 
feature have to also have the directive enabled.

Can't remember if also need to add:

EnableSendfile On

to enable it in Apache itself. I don't think so.

Graham

> On 12 Jan 2024, at 9:14 am, Graham Dumpleton  
> wrote:
> 
> Also not sure whether it will help or not, but if the data you are sending is 
> stored in a file and not generated on demand, then you might consider using 
> the WSGI file_wrapper extension instead.
> 
> https://modwsgi.readthedocs.io/en/master/user-guides/file-wrapper-extension.html
> 
> I don't know how this will behave when buffer fills up since when working 
> properly it is all handled in the OS kernel and not in Apache.
> 
> Along similar lines, if is stored as a file, you might try mod_sendfile. It 
> also would use kernel sendfile mechanism, but way it interacts may also see 
> different behaviour in your situation.
> 
> Graham
> 
>> On 12 Jan 2024, at 1:38 am, Greg Popp  wrote:
>> 
>> Thank you very much! This is most helpful, though I don't think any of them 
>> will actually solve my issues, for many of the reasons you mentioned.
>> 
>> I was thinking that perhaps the mod_wsgi interface had access to the file 
>> descriptor for the network socket used by Apache and could call "select" to 
>> see if it had enough buffer space for the requested write. If it didn't, it 
>> could (optionally) sleep some configurable duration and try again some 
>> configurable number of times. I understand though, that for most 
>> applications this would not be necessary.
>> 
>> Yesterday, I tried implementing that same behavior in my wsgi app. I don't 
>> set the SendBufferSize and so use the system default. I grab the system TCP 
>> send buff value by running the 'sysctl' command. Then I keep track of the 
>> total bytes sent. If that value exceeds the system tcp send queue value, I 
>> run the 'ss' command from within my wsgi app to grab the Send-Q value for 
>> this connection (fortunately wsgi gives us the source-ip and source-port and 
>> I can filter the 'ss' output using that). If the Send-Q value is too high to 
>> accommodate another write, I sleep a second and try again until I get enough 
>> space. It's kind of a Rube Goldberg solution, but so far it seems to be 
>> working!
>> 
>> Thank you for taking the time to answer my questions! I very much appreciate 
>> the assistance!
>> 
>> On Wednesday, January 10, 2024 at 3:38:51 PM UTC-6 Graham Dumpleton wrote:
>>> So what you are encountering is limitations in the socket buffer size 
>>> enforced by the operating system, in combination with Apache httpd applying 
>>> a socket timeout.
>>> 
>>> In other words what happens is that the HTTP client isn't reading data and 
>>> so the operating system level socket buffer fills up. At that point the 
>>> Apache httpd write of the response data blocks with it eventually timing 
>>> out, causing the initial error you see. In that situation Apache httpd will 
>>> close down the connection, which results in you seeing the second error 
>>> when still trying to write out more data anyway.
>>> 
>>> You may be able to adjust some Apache configuration settings to try and 
>>> solve this, but it would affect all requests in the context which you apply 
>>> the configuration (dependent on whether done in server, VirtualHost, 
>>> Directory or Location contexts). So not something you could selectively do 
>>> on a per client basis.
>>> 
>>> The first Apache directive to look at is SendBufferSize.
>>> 
>>> https://httpd.apache.org/docs/2.4/mod/mpm_common.html#sendbuffersize
>>> 
>>> If this is not set it should default to 0, which means it uses the 
>>> operating system default.
>>> 
>>> So you might be able to fiddle with this by setting it larger than the 
>>> operating system default (although there is still some upper bound set by 
>>> operating system you can go to).
>>> 
>>> The next Apache directive to look at is Timeout.
>>> 
>>> https://httpd.apache.org/docs/2.4/mod/core.html#timeout
>>> 
>>> This would usually default to 60 seconds but some Linux distributions may 
>>> override this in the Apa

Re: [modwsgi] Using write with large amounts of data causing disconnects

[Graham Dumpleton]

Also not sure whether it will help or not, but if the data you are sending is 
stored in a file and not generated on demand, then you might consider using the 
WSGI file_wrapper extension instead.

https://modwsgi.readthedocs.io/en/master/user-guides/file-wrapper-extension.html

I don't know how this will behave when buffer fills up since when working 
properly it is all handled in the OS kernel and not in Apache.

Along similar lines, if is stored as a file, you might try mod_sendfile. It 
also would use kernel sendfile mechanism, but way it interacts may also see 
different behaviour in your situation.

Graham

> On 12 Jan 2024, at 1:38 am, Greg Popp  wrote:
> 
> Thank you very much! This is most helpful, though I don't think any of them 
> will actually solve my issues, for many of the reasons you mentioned.
> 
> I was thinking that perhaps the mod_wsgi interface had access to the file 
> descriptor for the network socket used by Apache and could call "select" to 
> see if it had enough buffer space for the requested write. If it didn't, it 
> could (optionally) sleep some configurable duration and try again some 
> configurable number of times. I understand though, that for most applications 
> this would not be necessary.
> 
> Yesterday, I tried implementing that same behavior in my wsgi app. I don't 
> set the SendBufferSize and so use the system default. I grab the system TCP 
> send buff value by running the 'sysctl' command. Then I keep track of the 
> total bytes sent. If that value exceeds the system tcp send queue value, I 
> run the 'ss' command from within my wsgi app to grab the Send-Q value for 
> this connection (fortunately wsgi gives us the source-ip and source-port and 
> I can filter the 'ss' output using that). If the Send-Q value is too high to 
> accommodate another write, I sleep a second and try again until I get enough 
> space. It's kind of a Rube Goldberg solution, but so far it seems to be 
> working!
> 
> Thank you for taking the time to answer my questions! I very much appreciate 
> the assistance!
> 
> On Wednesday, January 10, 2024 at 3:38:51 PM UTC-6 Graham Dumpleton wrote:
>> So what you are encountering is limitations in the socket buffer size 
>> enforced by the operating system, in combination with Apache httpd applying 
>> a socket timeout.
>> 
>> In other words what happens is that the HTTP client isn't reading data and 
>> so the operating system level socket buffer fills up. At that point the 
>> Apache httpd write of the response data blocks with it eventually timing 
>> out, causing the initial error you see. In that situation Apache httpd will 
>> close down the connection, which results in you seeing the second error when 
>> still trying to write out more data anyway.
>> 
>> You may be able to adjust some Apache configuration settings to try and 
>> solve this, but it would affect all requests in the context which you apply 
>> the configuration (dependent on whether done in server, VirtualHost, 
>> Directory or Location contexts). So not something you could selectively do 
>> on a per client basis.
>> 
>> The first Apache directive to look at is SendBufferSize.
>> 
>> https://httpd.apache.org/docs/2.4/mod/mpm_common.html#sendbuffersize
>> 
>> If this is not set it should default to 0, which means it uses the operating 
>> system default.
>> 
>> So you might be able to fiddle with this by setting it larger than the 
>> operating system default (although there is still some upper bound set by 
>> operating system you can go to).
>> 
>> The next Apache directive to look at is Timeout.
>> 
>> https://httpd.apache.org/docs/2.4/mod/core.html#timeout
>> 
>> This would usually default to 60 seconds but some Linux distributions may 
>> override this in the Apache configuration they ship.
>> 
>> In very old Apache versions this actually defaulted to 300 seconds, but it 
>> was made lower at some point.
>> 
>> If playing with these, do be careful since they cause increased memory usage 
>> or cause other undesirable effects depending on traffic profile your server 
>> gets.
>> 
>> One other thing you may be able to use is mod_ratelimit.
>> 
>> https://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html
>> 
>> I have never actually used this and not exactly sure how it works, so is a 
>> bit of a guess, but you may be able to use this to slow down how quickly 
>> your application outputs the data.
>> 
>> I am assuming here that this module will introduce waits into your 
>> application, by blocking your writes for a

Re: [modwsgi] Using write with large amounts of data causing disconnects

[Graham Dumpleton]

So what you are encountering is limitations in the socket buffer size enforced 
by the operating system, in combination with Apache httpd applying a socket 
timeout.

In other words what happens is that the HTTP client isn't reading data and so 
the operating system level socket buffer fills up. At that point the Apache 
httpd write of the response data blocks with it eventually timing out, causing 
the initial error you see. In that situation Apache httpd will close down the 
connection, which results in you seeing the second error when still trying to 
write out more data anyway.

You may be able to adjust some Apache configuration settings to try and solve 
this, but it would affect all requests in the context which you apply the 
configuration (dependent on whether done in server, VirtualHost, Directory or 
Location contexts). So not something you could selectively do on a per client 
basis.

The first Apache directive to look at is SendBufferSize.

https://httpd.apache.org/docs/2.4/mod/mpm_common.html#sendbuffersize

If this is not set it should default to 0, which means it uses the operating 
system default.

So you might be able to fiddle with this by setting it larger than the 
operating system default (although there is still some upper bound set by 
operating system you can go to).

The next Apache directive to look at is Timeout.

https://httpd.apache.org/docs/2.4/mod/core.html#timeout

This would usually default to 60 seconds but some Linux distributions may 
override this in the Apache configuration they ship.

In very old Apache versions this actually defaulted to 300 seconds, but it was 
made lower at some point.

If playing with these, do be careful since they cause increased memory usage or 
cause other undesirable effects depending on traffic profile your server gets.

One other thing you may be able to use is mod_ratelimit.

https://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

I have never actually used this and not exactly sure how it works, so is a bit 
of a guess, but you may be able to use this to slow down how quickly your 
application outputs the data.

I am assuming here that this module will introduce waits into your application, 
by blocking your writes for a bit, to keep the flow of data being written by it 
under the rate limit. This would have the effect of not stuffing so much data 
into the response pipeline such that things work better with slower clients. 
Obviously using it would though penalise faster clients but you might find an 
acceptable balance by setting a higher rate limit for the initial burst of data 
and then using a lower rate after that.

Graham


> On 11 Jan 2024, at 7:09 am, Greg Popp  wrote:
> 
> embedded
> 
> On Wednesday, January 10, 2024 at 1:32:52 PM UTC-6 Graham Dumpleton wrote:
>> Are you using mod_wsgi embedded mode or daemon mode?
>> 
>> Graham
>> 
>> 
>>> On 11 Jan 2024, at 2:44 am, Greg Popp > wrote:
>>> 
>> 
>>> Hello!
>>> 
>>> My version of mod_wsgi is running on a Centos-7 system and is at version 
>>> 3.4, (I know - very old) with python 2.7
>>> 
>>> I have been using mod_wsgi for a python application that runs a 
>>> command-line program and marshals the output of the command line program 
>>> back to an http client. The data being sent is binary and can be tens of 
>>> gigs in size.
>>> 
>>> This app is "unconventional", in that it calls 'write' directly, instead of 
>>> returning an iterable. The problem I have had recently, is that some 
>>> clients are slow to read the data and the TCP buffer gets filled up. When 
>>> this happens, the next call to write on a full buffer causes a "failed to 
>>> write data" exception (which I trap) but if I try again to send the data I 
>>> get "client connection closed".
>>> 
>>> Is there some config setting or methodology I can use to alleviate this 
>>> issue? In other words, some way to back off and wait for the buffer to 
>>> drain sufficiently to resume sending the data? OR - is there some way to 
>>> get the current size (fullness) of the TCP write buffer on the connected 
>>> socket? (Something like what you see from the 'ss' command line utility 
>>> "Send-Q" column). If I could tell how full it is and what the max size is, 
>>> I could implement a sleep/retry cycle of some kind.
>>> 
>>> I have looked - even in the source code - but haven't been able to figure 
>>> it out if there is a way to achieve this.  Thanks in advance, for your 
>>> attention.
>>> 
>>> 
>>> 
>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Gro

Re: [modwsgi] Using write with large amounts of data causing disconnects

[Graham Dumpleton]

Are you using mod_wsgi embedded mode or daemon mode?

Graham

> On 11 Jan 2024, at 2:44 am, Greg Popp  wrote:
> 
> Hello!
> 
> My version of mod_wsgi is running on a Centos-7 system and is at version 3.4, 
> (I know - very old) with python 2.7
> 
> I have been using mod_wsgi for a python application that runs a command-line 
> program and marshals the output of the command line program back to an http 
> client. The data being sent is binary and can be tens of gigs in size.
> 
> This app is "unconventional", in that it calls 'write' directly, instead of 
> returning an iterable. The problem I have had recently, is that some clients 
> are slow to read the data and the TCP buffer gets filled up. When this 
> happens, the next call to write on a full buffer causes a "failed to write 
> data" exception (which I trap) but if I try again to send the data I get 
> "client connection closed".
> 
> Is there some config setting or methodology I can use to alleviate this 
> issue? In other words, some way to back off and wait for the buffer to drain 
> sufficiently to resume sending the data? OR - is there some way to get the 
> current size (fullness) of the TCP write buffer on the connected socket? 
> (Something like what you see from the 'ss' command line utility "Send-Q" 
> column). If I could tell how full it is and what the max size is, I could 
> implement a sleep/retry cycle of some kind.
> 
> I have looked - even in the source code - but haven't been able to figure it 
> out if there is a way to achieve this.  Thanks in advance, for your attention.
> 
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/3d97c06f-38ff-4345-af2f-eb86c2ef204cn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/36744648-A2C5-4C0B-9CCB-593AD1BA77D1%40gmail.com.

Re: [modwsgi] mod_wsgi-express: command not found

[Graham Dumpleton]

See comments below.

> On 14 Dec 2023, at 10:41 pm, yoshitaka okada  
> wrote:
> 
> This is the apache configuration. It was working before I updated python to 
> 3.11.
> 
> ```
> 
> # The ServerName directive sets the request scheme, hostname and port 
> that
> # the server uses to identify itself. This is used when creating
> # redirection URLs. In the context of virtual hosts, the ServerName
> # specifies what hostname must appear in the request's Host: header to
> # match this virtual host. For the default virtual host (this file) 
> this
> # value is not decisive as it is used as a last resort host 
> regardless.
> # However, you must set it for any further virtual host explicitly.
> ServerName www.henojiya.net
> 
> ServerAdmin webmaster@localhost
> DocumentRoot /var/www/html
> 
> # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
> # error, crit, alert, emerg.
> # It is also possible to configure the loglevel for particular
> # modules, e.g.
> #LogLevel info ssl:warn
> 
> ErrorLog ${APACHE_LOG_DIR}/error.log
> CustomLog ${APACHE_LOG_DIR}/access.log combined
> 
> # For most configuration files from conf-available/, which are
> # enabled or disabled at a global level, it is possible to
> # include a line for only one particular virtual host. For example the
> # following line enables the CGI configuration for this host only
> # after it has been globally disabled with "a2disconf".
> #Include conf-available/serve-cgi-bin.conf
> 
> 
> LoadModule wsgi_module modules/mod_wsgi.so
> LoadModule wsgi_module 
> /var/www/html/venv/lib/python3.11/site-packages/mod_wsgi/server/mod_wsgi-py311.cpython-311-x86_64-linux-gnu.so

You should not have:

LoadModule wsgi_module modules/mod_wsgi.so

only the second one:

LoadModule wsgi_module 
/var/www/html/venv/lib/python3.11/site-packages/mod_wsgi/server/mod_wsgi-py311.cpython-311-x86_64-linux-gnu.so

The first one is trying to pick up system installed mod_wsgi and would take 
precedence, failing if it doesn't exist, and using wrong Python version or 
causing other problems if it did. So only use second LoadModule line.

> WSGIScriptAlias / /var/www/html/portfolio/mysite/mysite/wsgi.py
> WSGIPythonPath /var/www/html/portfolio/mysite

The WSGIPythonPath line here only affects embedded mode which you aren't using.

Remove WSGIPythonPath, but also add outside of the VirtualHost:

WSGIRestrictEmbedded On

so that embedded mode is disabled.

> WSGIPythonHome /var/www/html/venv

WSGIPythonHome is technically not needed when disabled embedded mode.

> WSGIDaemonProcess wsgi_app python-home=/var/www/html/venv 
> python-path=/var/www/html/portfolio/mysite
> WSGIProcessGroup wsgi_app
> WSGISocketPrefix /var/run/wsgi
> WSGIApplicationGroup %{GLOBAL}
> 
> # css, javascript etc
> Alias /static/ /var/www/html/portfolio/mysite/static/
> 
>   Require all granted
> 
> ```
> 
> After deleting the log, when I restart and check the status, the following 
> error appears.
> 
> ```
> [Thu Dec 14 20:29:36.782463 2023] [ssl:warn] [pid 1313720:tid 
> 140180280511552] AH01909: ik1-336-28225.vs.sakura.ne.jp:443:0 server 
> certificate does NOT include an ID which matches the server name
> [Thu Dec 14 20:29:36.788504 2023] [so:warn] [pid 1313720:tid 140180280511552] 
> AH01574: module wsgi_module is already loaded, skipping
> [Thu Dec 14 20:29:36.788520 2023] [so:warn] [pid 1313720:tid 140180280511552] 
> AH01574: module wsgi_module is already loaded, skipping
> [Thu Dec 14 20:29:36.800040 2023] [ssl:warn] [pid 1313721:tid 
> 140180280511552] AH01909: ik1-336-28225.vs.sakura.ne.jp:443:0 server 
> certificate does NOT include an ID which matches the server name
> [Thu Dec 14 20:29:36.800990 2023] [mpm_event:notice] [pid 1313721:tid 
> 140180280511552] AH00489: Apache/2.4.41 (Ubuntu) OpenSSL/1.1.1f 
> mod_wsgi/4.6.8 Python/3.8 configured -- resuming normal operations
> [Thu Dec 14 20:29:36.801010 2023] [core:notice] [pid 1313721:tid 
> 140180280511552] AH00094: Command line: '/usr/sbin/apache2'
> ```
> 
> The mod_wsgi operating system package may be installed.
> I'll try resetting the OS once.
> 
> thank you
> 2023年12月14日木曜日 19:44:38 UTC+9 Graham Dumpleton:
>> 
>>> On 14 Dec 2023, at 9:42 pm, Graham Dumpleton > 
>>> wrote:
>>> 
>>> If using pip install version of mod_wsgi, make sure that you haven't 
>>> installed operating system package for mod_wsgi and have configuration 
>>> using that still laying around. In other words, you should a

Re: [modwsgi] Correlation between mod_wsgi Daemon Processes and apache mpm_worker

[Graham Dumpleton]

The issue with the process-group option you have is that it doesn't match the 
name of the process group. You have "custom" instead of "ipt".

To be honest I even missed you had the process-group option in there. Since 
didn't match you should actually have got an error. So maybe you do have it 
correct.

Note another video to watch which touches on performance is:

https://www.youtube.com/watch?v=SGleKfigMsk
Using benchmarks to understand how WSGI servers work. by Graham Dumpleton
youtube.com


BTW, make sure you have:

WSGIRestrictEmbedded On

set in global Apache configuration if using daemon process mode.

Graham

> On 15 Dec 2023, at 4:49 am, Manu Itutur  wrote:
> 
> Thanks for your answer,
> 
> In my file I use absolute path, I remove some "sensitive" data, therefore 
> it's then a relative path, sorry for the confusion. 
> 
> I already watched both video couple of days ago, but I guess I missed 
> something. I will check process-group option in  WSGIScriptAlias, hope things 
> will be clarified.
> 
> 
>  
> 
> On Wednesday, December 13, 2023 at 8:25:46 PM UTC+1 Graham Dumpleton wrote:
>> BTW the location given in python-path, second argument to WSGIScriptAlias 
>> and argument to Directory directive are supposed to be absolute paths, not 
>> relative. Use of a relative path might cause incorrect results.
>> 
>> For a virtual environment you should not use python-path like that anyway. 
>> Instead use python-home to virtual environment root. See:
>> 
>> Virtual Environments — mod_wsgi 5.0.0 documentation
>> modwsgi.readthedocs.io
>> 
>>  
>> <https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html>Virtual
>>  Environments — mod_wsgi 5.0.0 documentation 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html>
>> modwsgi.readthedocs.io 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html>
>>
>> <https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html>
>> 
>> 
>>> On 14 Dec 2023, at 1:45 am, Manu Itutur > wrote:
>>> 
>> 
>>> WSGIDaemonProcess ipt python-path=virtualenv/lib/python3.7/site-packages 
>>> processes=7 threads=2 display-name=custom-apache
>>> WSGIScriptAlias / conf/wsgi.preprod.py <http://wsgi.preprod.py/> 
>>> process-group=custom application-group=%{GLOBAL}
>>> WSGIApplicationGroup %{GLOBAL}
>>> 
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/9973f79c-6265-4cee-a876-262b09975fa4n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/modwsgi/9973f79c-6265-4cee-a876-262b09975fa4n%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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/891D814F-74F0-4BB5-95E3-E7AEDC8FC565%40gmail.com.

Re: [modwsgi] mod_wsgi-express: command not found

[Graham Dumpleton]

> On 14 Dec 2023, at 9:42 pm, Graham Dumpleton  
> wrote:
> 
> If using pip install version of mod_wsgi, make sure that you haven't 
> installed operating system package for mod_wsgi and have configuration using 
> that still laying around. In other words, you should also have line:

Mean to say "In other words, you should NOT also have line"...

> 
> LoadModule wsgi_module modules/mod_wsgi.so <http://mod_wsgi.so/>
> 
> That should be replaced with what "mod_wsgi-express module-config" output.
> 
> I can't comment any further if still got an issue without seeing the Apache 
> configuration you used and what errors are appearing in any error logs.
> 
>> On 14 Dec 2023, at 9:37 pm, yoshitaka okada  
>> wrote:
>> 
>> Thank you master :)
>> The command now works.
>> 
>> ```
>> (venv) rootik1-336-28225:/home/ubuntu# mod_wsgi-express module-config
>> LoadModule wsgi_module 
>> "/var/www/html/venv/lib/python3.11/site-packages/mod_wsgi/server/mod_wsgi-py311.cpython-311-x86_64-linux-gnu.so
>>  <http://mod_wsgi-py311.cpython-311-x86_64-linux-gnu.so/>"
>> ```
>> 
>> I replaced LOAD_MODULE with...
>> However, the web server that was previously working does not work at all 
>> even after restarting.
>> ```
>> # vi /etc/apache2/sites-enabled/000-default.conf
>> ```
>> 2023年12月14日木曜日 18:57:59 UTC+9 Graham Dumpleton:
>>> The mod_wsgi-express command is available when installing mod_wsgi using 
>>> pip.
>>> 
>>> See:
>>> 
>>> 
>>> 
>>> mod-wsgi
>>> pypi.org
>>>  <https://pypi.org/project/mod-wsgi/>mod-wsgi 
>>> <https://pypi.org/project/mod-wsgi/>
>>> pypi.org <https://pypi.org/project/mod-wsgi/>
>>> 
>>> and watch:
>>> 
>>> 
>>> Graham Dumpleton - Secrets of a WSGI master. - PyCon 2018
>>> youtube.com
>>>  <https://www.youtube.com/watch?v=CPz0s1CQsTE&t=5s>Graham Dumpleton - 
>>> Secrets of a WSGI master. - PyCon 2018 
>>> <https://www.youtube.com/watch?v=CPz0s1CQsTE&t=5s>
>>> youtube.com <https://www.youtube.com/watch?v=CPz0s1CQsTE&t=5s>
>>> If you want to use configure/make/make install installation method rather 
>>> than pip (which doesn't provide mod_wsgi-express) and manually configure 
>>> Apache, then try running:
>>> 
>>>   ./configure --with=python=python3
>>> 
>>> By default it still looks for "python" which will only work if using Python 
>>> 2.X or a virtual environment with Python 3.
>>> 
>>> Graham
>>> 
>>> 
>>>> On 14 Dec 2023, at 8:42 pm, yoshitaka okada > 
>>>> wrote:
>>>> 
>>> 
>>>> hello :)
>>>> 
>>>> I am trying to upgrade a Django project on ubuntu.
>>>> However, now I am getting an Internal Server Error.
>>>> 
>>>> My environment is as follows
>>>> ```
>>>> (venv) ubuntu@ik1-336-28225:/usr/src$ cat /etc/issue
>>>> Ubuntu 20.04.3 LTS \n \l
>>>> ```
>>>> ```
>>>> apachectl -v
>>>>   Server version: Apache/2.4.41 (Ubuntu)
>>>>   Server built:   2023-10-26T13:54:09
>>>> ``` 
>>>> ```
>>>> (venv) ubuntu@ik1-336-28225:/usr/src$ ls
>>>>   Python-3.11.7linux-headers-5.4.0-167-generic
>>>>   linux-headers-5.4.0-137  linux-headers-5.4.0-169
>>>>   linux-headers-5.4.0-137-generic  linux-headers-5.4.0-169-generic
>>>>   linux-headers-5.4.0-167  mod_wsgi-5.0.0
>>>> ```
>>>> 
>>>> The libraries installed in the django project are as follows:
>>>> https://github.com/duri0214/portfolio/blob/master/requirements.txt
>>>> 
>>>> Now, Apparently there is a useful command called mod_wsgi-express.
>>>> 
>>>> The configure command probably worked.
>>>> No, but maybe it's not working... ?
>>>> ```
>>>> (venv) ubuntu@ik1-336-28225:/usr/src/mod_wsgi-5.0.0$ sudo ./configure
>>>> [sudo] password for ubuntu:
>>>> checking for apxs2... /usr/bin/apxs2
>>>> checking for gcc... gcc
>>>> checking whether the C compiler works... yes
>>>> checking for C compiler default output file name... a.out
>>>> checking for suffix of executables...
>>>> checking whether we are cross compiling... no
>>>> check

Re: [modwsgi] mod_wsgi-express: command not found

[Graham Dumpleton]

If using pip install version of mod_wsgi, make sure that you haven't installed 
operating system package for mod_wsgi and have configuration using that still 
laying around. In other words, you should also have line:

LoadModule wsgi_module modules/mod_wsgi.so <http://mod_wsgi.so/>

That should be replaced with what "mod_wsgi-express module-config" output.

I can't comment any further if still got an issue without seeing the Apache 
configuration you used and what errors are appearing in any error logs.

> On 14 Dec 2023, at 9:37 pm, yoshitaka okada  
> wrote:
> 
> Thank you master :)
> The command now works.
> 
> ```
> (venv) rootik1-336-28225:/home/ubuntu# mod_wsgi-express module-config
> LoadModule wsgi_module 
> "/var/www/html/venv/lib/python3.11/site-packages/mod_wsgi/server/mod_wsgi-py311.cpython-311-x86_64-linux-gnu.so
>  <http://mod_wsgi-py311.cpython-311-x86_64-linux-gnu.so/>"
> ```
> 
> I replaced LOAD_MODULE with...
> However, the web server that was previously working does not work at all even 
> after restarting.
> ```
> # vi /etc/apache2/sites-enabled/000-default.conf
> ```
> 2023年12月14日木曜日 18:57:59 UTC+9 Graham Dumpleton:
>> The mod_wsgi-express command is available when installing mod_wsgi using pip.
>> 
>> See:
>> 
>> 
>> 
>> mod-wsgi
>> pypi.org
>>  <https://pypi.org/project/mod-wsgi/>mod-wsgi 
>> <https://pypi.org/project/mod-wsgi/>
>> pypi.org <https://pypi.org/project/mod-wsgi/>
>> 
>> and watch:
>> 
>> 
>> Graham Dumpleton - Secrets of a WSGI master. - PyCon 2018
>> youtube.com
>>  <https://www.youtube.com/watch?v=CPz0s1CQsTE&t=5s>Graham Dumpleton - 
>> Secrets of a WSGI master. - PyCon 2018 
>> <https://www.youtube.com/watch?v=CPz0s1CQsTE&t=5s>
>> youtube.com <https://www.youtube.com/watch?v=CPz0s1CQsTE&t=5s>
>> If you want to use configure/make/make install installation method rather 
>> than pip (which doesn't provide mod_wsgi-express) and manually configure 
>> Apache, then try running:
>> 
>>   ./configure --with=python=python3
>> 
>> By default it still looks for "python" which will only work if using Python 
>> 2.X or a virtual environment with Python 3.
>> 
>> Graham
>> 
>> 
>>> On 14 Dec 2023, at 8:42 pm, yoshitaka okada > 
>>> wrote:
>>> 
>> 
>>> hello :)
>>> 
>>> I am trying to upgrade a Django project on ubuntu.
>>> However, now I am getting an Internal Server Error.
>>> 
>>> My environment is as follows
>>> ```
>>> (venv) ubuntu@ik1-336-28225:/usr/src$ cat /etc/issue
>>> Ubuntu 20.04.3 LTS \n \l
>>> ```
>>> ```
>>> apachectl -v
>>>   Server version: Apache/2.4.41 (Ubuntu)
>>>   Server built:   2023-10-26T13:54:09
>>> ``` 
>>> ```
>>> (venv) ubuntu@ik1-336-28225:/usr/src$ ls
>>>   Python-3.11.7linux-headers-5.4.0-167-generic
>>>   linux-headers-5.4.0-137  linux-headers-5.4.0-169
>>>   linux-headers-5.4.0-137-generic  linux-headers-5.4.0-169-generic
>>>   linux-headers-5.4.0-167  mod_wsgi-5.0.0
>>> ```
>>> 
>>> The libraries installed in the django project are as follows:
>>> https://github.com/duri0214/portfolio/blob/master/requirements.txt
>>> 
>>> Now, Apparently there is a useful command called mod_wsgi-express.
>>> 
>>> The configure command probably worked.
>>> No, but maybe it's not working... ?
>>> ```
>>> (venv) ubuntu@ik1-336-28225:/usr/src/mod_wsgi-5.0.0$ sudo ./configure
>>> [sudo] password for ubuntu:
>>> checking for apxs2... /usr/bin/apxs2
>>> checking for gcc... gcc
>>> checking whether the C compiler works... yes
>>> checking for C compiler default output file name... a.out
>>> checking for suffix of executables...
>>> checking whether we are cross compiling... no
>>> checking for suffix of object files... o
>>> checking whether we are using the GNU C compiler... yes
>>> checking whether gcc accepts -g... yes
>>> checking for gcc option to accept ISO C89... none needed
>>> checking for prctl... yes
>>> checking Apache version... 2.4.41
>>> checking for python... no
>>> ./configure: line 2823: python: command not found
>>> ./configure: line 2827: python: command not found
>>> ./configure: line 2835: python: command not found
>>> ./configure: line 2840: python: command not found
>

Re: [modwsgi] mod_wsgi-express: command not found

[Graham Dumpleton]

The mod_wsgi-express command is available when installing mod_wsgi using pip.

See:


https://pypi.org/project/mod-wsgi/
mod-wsgi
pypi.org

and watch:

https://www.youtube.com/watch?v=CPz0s1CQsTE&t=5s
Graham Dumpleton - Secrets of a WSGI master. - PyCon 2018
youtube.com

If you want to use configure/make/make install installation method rather than 
pip (which doesn't provide mod_wsgi-express) and manually configure Apache, 
then try running:

  ./configure --with=python=python3

By default it still looks for "python" which will only work if using Python 2.X 
or a virtual environment with Python 3.

Graham

> On 14 Dec 2023, at 8:42 pm, yoshitaka okada  
> wrote:
> 
> hello :)
> 
> I am trying to upgrade a Django project on ubuntu.
> However, now I am getting an Internal Server Error.
> 
> My environment is as follows
> ```
> (venv) ubuntu@ik1-336-28225:/usr/src$ cat /etc/issue
> Ubuntu 20.04.3 LTS \n \l
> ```
> ```
> apachectl -v
>   Server version: Apache/2.4.41 (Ubuntu)
>   Server built:   2023-10-26T13:54:09
> ``` 
> ```
> (venv) ubuntu@ik1-336-28225:/usr/src$ ls
>   Python-3.11.7linux-headers-5.4.0-167-generic
>   linux-headers-5.4.0-137  linux-headers-5.4.0-169
>   linux-headers-5.4.0-137-generic  linux-headers-5.4.0-169-generic
>   linux-headers-5.4.0-167  mod_wsgi-5.0.0
> ```
> 
> The libraries installed in the django project are as follows:
> https://github.com/duri0214/portfolio/blob/master/requirements.txt
> 
> Now, Apparently there is a useful command called mod_wsgi-express.
> 
> The configure command probably worked.
> No, but maybe it's not working... ?
> ```
> (venv) ubuntu@ik1-336-28225:/usr/src/mod_wsgi-5.0.0$ sudo ./configure
> [sudo] password for ubuntu:
> checking for apxs2... /usr/bin/apxs2
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for prctl... yes
> checking Apache version... 2.4.41
> checking for python... no
> ./configure: line 2823: python: command not found
> ./configure: line 2827: python: command not found
> ./configure: line 2835: python: command not found
> ./configure: line 2840: python: command not found
> ./configure: line 2854: python: command not found
> ./configure: line 2857: python: command not found
> ./configure: line 2860: python: command not found
> ./configure: line 2863: python: command not found
> ./configure: line 2866: python: command not found
> ./configure: line 2892: python: command not found
> ./configure: line 2895: python: command not found
> configure: creating ./config.status
> config.status: creating Makefile
> ```
> 
> make command doesn't work either.
> ```
> (venv) ubuntu@ik1-336-28225:/usr/src$ make
> make: *** No targets specified and no makefile found.  Stop.
> ```
> 
> And this command fails, so I'm at a loss as to where I'm going wrong. Is 
> there anyone who can help?
> ```
> (venv) ubuntu@ik1-336-28225:/usr/src$ mod_wsgi-express module-config
> mod_wsgi-express: command not found
> ```
> 
> vi /etc/apache2/sites-enabled/000-default.conf
> ```
>   :
> LoadModule wsgi_module modules/mod_wsgi.so
>   :
> ```
> Load module is probably fine.
> 
> If any information is missing, please let us know　:)
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/46d1e4b2-c376-40d5-b583-c07c1801de3en%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/modwsgi/46d1e4b2-c376-40d5-b583-c07c1801de3en%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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/0A3E6148-FE75-45A6-B03B-335E0F77224A%40gmail.com.

Re: [modwsgi] Correlation between mod_wsgi Daemon Processes and apache mpm_worker

[Graham Dumpleton]

BTW the location given in python-path, second argument to WSGIScriptAlias and 
argument to Directory directive are supposed to be absolute paths, not 
relative. Use of a relative path might cause incorrect results.

For a virtual environment you should not use python-path like that anyway. 
Instead use python-home to virtual environment root. See:

https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html

> On 14 Dec 2023, at 1:45 am, Manu Itutur  wrote:
> 
> WSGIDaemonProcess ipt python-path=virtualenv/lib/python3.7/site-packages 
> processes=7 threads=2 display-name=custom-apache
> WSGIScriptAlias / conf/wsgi.preprod.py process-group=custom 
> application-group=%{GLOBAL}
> WSGIApplicationGroup %{GLOBAL}
> 

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/36877CF7-6FC2-4B35-86E1-45E80C0DCA32%40gmail.com.

Re: [modwsgi] Correlation between mod_wsgi Daemon Processes and apache mpm_worker

[Graham Dumpleton]

You are missing WSGIProcessGroup directive or process-group option to 
WSGIScriptAlias, so you aren't even delegating requests to be handled by the 
mod_wsgi daemon process group. That will be in part why things are not making 
sense.

For more background go watch:

https://www.youtube.com/watch?v=H6Q3l11fjU0
https://www.youtube.com/watch?v=k6Erh7oHvns

Graham

> On 14 Dec 2023, at 1:45 am, Manu Itutur  wrote:
> 
> Hello, 
> 
> I'm having an hard time understanding the correlation between mod_wsgi Daemon 
> Processes and apache mpm_worker (if there is any). 
> 
> I'm running a Django application on an Ubuntu 22.04 Apache Server, and I 
> would like to optimise the CPU / RAM usage of it, as it looks like when there 
> is a hight number of user / requests, the CPU usage is limited to around 60%. 
> 
> 
> My Apache configuration is currently the following:
> 
> WSGIDaemonProcess ipt python-path=virtualenv/lib/python3.7/site-packages 
> processes=7 threads=2 display-name=custom-apache
> WSGIScriptAlias / conf/wsgi.preprod.py process-group=custom 
> application-group=%{GLOBAL}
> WSGIApplicationGroup %{GLOBAL}
> 
>   
> Require all granted
> Order allow,deny
> Allow from all
>   
> 
> 
> And my MPM conf file (which are the default settings of Apache2):
> 
> 
>   StartServers 5
>   MinSpareServers   5
>   MaxSpareServers  10
>   MaxRequestWorkers 150
>   MaxConnectionsPerChild   0
> 
> 
> 
> I read multiple time this documentation 
> https://modwsgi.readthedocs.io/en/master/user-guides/processes-and-threading.html#the-mod-wsgi-daemon-processes
>  but I don't realy understand how the mpm_prefork_module and the 
> WSGIDaemonProcess combine with each other and how to tweak the value 
> "safely". 
> 
> Should I only increase processes and threads at the WSGIDaemonProcess without 
> modifying the mpm_prefork_module? Or are both conf related? 
> 
> Thanks for your clarification
> 
> Emmanuel 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/d278edf0-017d-4a2b-bf14-98f21b21346bn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/0488C599-A832-4143-9D7F-EE0A6FE16AA6%40gmail.com.

Re: [modwsgi] Inquiry about Possible Cache Mechanism or Issue in mod_wsgi with ApacheServer and Django

[Graham Dumpleton]

Since you are on Windows there would be only one process.

So long as you aren't defining multiple VirtualHost definitions with separate 
WSGIScriptAlias for each, then all requests for the Django app should be in 
same interpreter context and data is common. So not a problem with requests 
being handled across multiple processes and thus different interpreter 
contexts, or use of multiple sub interpreters in one process.

The only way this might not be the case when have single process and 
interpreter context is if data you are accessing was for some reason stored in 
thread local storage within the process. That is, each request handler thread 
has its own copy of the data.

* https://docs.python.org/3/library/threading.html#thread-local-data

Usually one would know if your application is using thread local storage any 
why you were doing it that way. Also, what you would get in this case would be 
random based on which thread was used for a request and one client would not 
reliably always see same result.

All I can suggest right now is set:

LogLevel debug

and validate that for requests from each client that mod_wsgi is actually 
handling the request and that the request isn't being intercepted by a caching 
proxy or caching mechanism of Apache itself. Also look at access log of Apache 
as well.

There is nothing in mod_wsgi that does caching.

Other alternative is whether Django caching is interfering with things.

More intrusive to set up, but you could use a WSGI middleware to capture both 
request and response and see data at that point.

* 
https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#tracking-request-and-response

Graham

> On 5 Dec 2023, at 7:54 pm, 王省三  wrote:
> 
> My project is on Windows, and the relevant configuration in httpd.conf is as 
> follows: 
> LoadFile "C:\Program Files\myproject\Python\python37.dll"
> LoadModule wsgi_module "C:\Program 
> Files\myproject\Python\lib\site-packages\mod_wsgi\server\mod_wsgi.cp37-win32.pyd"
> WSGIPythonHome "C:\Program Files\myproject\Python"
> WSGIScriptAlias / "C:/Program Files/myproject/myapp/wsgi.py"
> WSGIPythonPath "C:/Program Files/myproject/myapp"
> 
> 
> 
> Require all granted
> 
> 
> 
> Alias /static "C:/Program Files/myproject/myapp/staticfiles"
> 
> AllowOverride None
> Options None
> Require all granted
> 
> 
> 
> 
> Header unset ETag
> Header set Cache-Control "max-age=0, no-cache, no-store, 
> must-revalidate"
>     Header set Pragma "no-cache"
> Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
> 
> 
> 
> 
> ThreadsPerChild 25
> MaxConnectionsPerChild 0
> 
> Graham Dumpleton 在 2023年12月5日 星期二下午1:39:18 [UTC+8] 的信中寫道：
>> There may not be only a single object because of how you have configured 
>> Apache/mod_wsgi.
>> 
>> Read:
>> 
>> * 
>> https://modwsgi.readthedocs.io/en/master/user-guides/processes-and-threading.html
>> 
>> Then post your configuration so can see whether you are using embedded mode 
>> or daemon mode of mod_wsgi, and if the latter how you have the daemon 
>> process group configured, plus whether you are correctly delegating requests 
>> to even be run in daemon node processes.
>> 
>> Graham
>> 
>> 
>>> On 5 Dec 2023, at 4:33 pm, 王省三 > wrote:
>>> 
>> 
>>> Dear mod_wsgi community,
>>> 
>>> I hope this message finds you well. I am encountering an issue in my 
>>> project setup, which involves ApacheServer, mod_wsgi, and Django. 
>>> Specifically, when accessing the project from both the company's internal 
>>> network and external network, it appears that different global objects are 
>>> being obtained, seemingly from different memory locations. This discrepancy 
>>> in global objects results in an increasing time difference between internal 
>>> and external networks.
>>> 
>>> In theory, there should only be one global object, and when using runserver 
>>> or employing Nginx or Waitress as reverse proxies, this issue does not 
>>> occur. Despite disabling cache-related settings in ApacheServer, the 
>>> problem persists.
>>> 
>>> I would like to inquire whether mod_wsgi has any caching mechanisms or if 
>>> there might be an underlying issue causing this behavior. Your insights and 
>>> guidance on how to address or troubleshoot this matter would be greatly 
>>> appreciated.
>>> 
>>> Thank you for your time and assistance.
>>> 
>>> Best regards, Arthur
>>

Re: [modwsgi] Inquiry about Possible Cache Mechanism or Issue in mod_wsgi with ApacheServer and Django

[Graham Dumpleton]

There may not be only a single object because of how you have configured 
Apache/mod_wsgi.

Read:

* 
https://modwsgi.readthedocs.io/en/master/user-guides/processes-and-threading.html

Then post your configuration so can see whether you are using embedded mode or 
daemon mode of mod_wsgi, and if the latter how you have the daemon process 
group configured, plus whether you are correctly delegating requests to even be 
run in daemon node processes.

Graham

> On 5 Dec 2023, at 4:33 pm, 王省三  wrote:
> 
> Dear mod_wsgi community,
> 
> I hope this message finds you well. I am encountering an issue in my project 
> setup, which involves ApacheServer, mod_wsgi, and Django. Specifically, when 
> accessing the project from both the company's internal network and external 
> network, it appears that different global objects are being obtained, 
> seemingly from different memory locations. This discrepancy in global objects 
> results in an increasing time difference between internal and external 
> networks.
> 
> In theory, there should only be one global object, and when using runserver 
> or employing Nginx or Waitress as reverse proxies, this issue does not occur. 
> Despite disabling cache-related settings in ApacheServer, the problem 
> persists.
> 
> I would like to inquire whether mod_wsgi has any caching mechanisms or if 
> there might be an underlying issue causing this behavior. Your insights and 
> guidance on how to address or troubleshoot this matter would be greatly 
> appreciated.
> 
> Thank you for your time and assistance.
> 
> Best regards, Arthur
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/bc088c4d-9859-40aa-bd7a-41b1b95b445bn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/2C296D9D-FE14-4D10-AAB5-C389B46AA7DF%40gmail.com.

Re: [modwsgi] Trac

[Graham Dumpleton]

An update to the TracInstall page would be helpful.

https://trac.edgewall.org/wiki/TracInstall

On Friday, 1 December 2023 at 07:56:40 UTC+11 jun...@gmail.com wrote:

> Python 3.5+ is supported since Trac 1.6.
>
> See https://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.6
>
> On Fri, Dec 1, 2023 at 5:42 Graham Dumpleton  
> wrote:
>
>> You should not use mod_wsgi-standalone package. You should use the 
>> standard mod_wsgi package and ensure that system Apache development package 
>> is installed so that mod_wsgi is compiled against and uses it instead.
>>
>> Next is that Trac provides only instructions for integrating with system 
>> Apache and does not provide instructions for integrating with 
>> mod_wsgi-express command line (which is another reason why can't use 
>> mod_wsgi-standalone package).
>>
>> So it is unclear how you might even have set things up if trying to use 
>> mod_wsgi-express. Either way, the tracd process should not be running, as 
>> that isn't how things work if embedding Trac with Apache/mod_wsgi.
>>
>> Instructions for using Trac with Apache/mod_wsgi can be found at:
>>
>> * https://trac.edgewall.org/wiki/TracModWSGI
>>
>> Also be aware that Trac only supports Python 2.7 and you cannot use 
>> Python 3.0.
>>
>> To be of any more help I would need to know more about how you are 
>> running things and configuring system Apache.
>>
>> Graham
>>
>>
>> On 1 Dec 2023, at 5:36 am, Doug Epling  wrote:
>>
>> I am determined to get this working.  The thing is developers write 
>> copious documentation, without revision dates, and technology does not 
>> stand still.
>>
>> I am down to one virtual environment with mod_wsgi-standalone in lib64/ 
>> with Python site-packages and with Trac in lib/ with site-packages.  The 
>> project is in /opt//.  tracd will start serving, but without 
>> its own server it will not cooperate.  mod_python-express will execute to 
>> show the snake whisky.  
>>
>> I have just learned of the new[ish] pipx command to work with 
>> virtualenv's, which seems promising.  But I am hoping someone could suggest 
>> a more direct route to China, so to speak.
>>
>> Thanks
>>
>> -- 
>> 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 modwsgi+u...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/4009c806-cb95-4dc2-baa9-f7b48251c309n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/4009c806-cb95-4dc2-baa9-f7b48251c309n%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 modwsgi+u...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/280DBABC-6516-40AF-BDDF-74C3A4057E1F%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/280DBABC-6516-40AF-BDDF-74C3A4057E1F%40gmail.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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/7df863cf-9532-4de2-aedc-ba86639164can%40googlegroups.com.

Re: [modwsgi] Trac

[Graham Dumpleton]

You should not use mod_wsgi-standalone package. You should use the standard 
mod_wsgi package and ensure that system Apache development package is installed 
so that mod_wsgi is compiled against and uses it instead.

Next is that Trac provides only instructions for integrating with system Apache 
and does not provide instructions for integrating with mod_wsgi-express command 
line (which is another reason why can't use mod_wsgi-standalone package).

So it is unclear how you might even have set things up if trying to use 
mod_wsgi-express. Either way, the tracd process should not be running, as that 
isn't how things work if embedding Trac with Apache/mod_wsgi.

Instructions for using Trac with Apache/mod_wsgi can be found at:

* https://trac.edgewall.org/wiki/TracModWSGI

Also be aware that Trac only supports Python 2.7 and you cannot use Python 3.0.

To be of any more help I would need to know more about how you are running 
things and configuring system Apache.

Graham

> On 1 Dec 2023, at 5:36 am, Doug Epling  wrote:
> 
> I am determined to get this working.  The thing is developers write copious 
> documentation, without revision dates, and technology does not stand still.
> 
> I am down to one virtual environment with mod_wsgi-standalone in lib64/ with 
> Python site-packages and with Trac in lib/ with site-packages.  The project 
> is in /opt//.  tracd will start serving, but without its own 
> server it will not cooperate.  mod_python-express will execute to show the 
> snake whisky.  
> 
> I have just learned of the new[ish] pipx command to work with virtualenv's, 
> which seems promising.  But I am hoping someone could suggest a more direct 
> route to China, so to speak.
> 
> Thanks
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/4009c806-cb95-4dc2-baa9-f7b48251c309n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/280DBABC-6516-40AF-BDDF-74C3A4057E1F%40gmail.com.

Re: [modwsgi] Apache mod_wsgi python server is giving 503

[Graham Dumpleton]

Can you supply the full log messages below from Apache error log with any 
prefixes so I can identify what output them.

The mod_wsgi code does emit a message "Python has shutdown", but doesn't emit a 
message "Connection closed to child with abortive shutdown".

So is important that can see the full log messages include any date/time stamp 
and prefixes. Any other messages around that time would also be useful.

If I had to guess, you are using some third party package for Python which 
assumes that if it has an internal error message that it can force a process 
shutdown using a signal or call of C level exit() function.

Also, although you see the messages "Resource temporarily unavailable" are they 
transient and after a moment requests start to be processed again?

> On 19 Oct 2023, at 10:01 am, Darshan Patil  wrote:
> 
> Hi,
> 
> I have my apache server where I am using mod_wsgi to run python endpoints 
> which serve images from the server. There are lot of requests hitting the 
> server and I started seeing errors like following:
> 
> Python has shutdown.
> 
> Connection closed to child with abortive shutdown.
> 
> Resource temporarily unavailable: mod_wsgi (pid=1211): Unable to connect to 
> WSGI daemon process 'app' on '/run/httpd/wsgi.10.0.1.sock' after multiple 
> attempts as listener backlog limit was exceeded or the socket does not exist.
> 
> I am not sure what is going on here, can anybody has clue what the problem 
> could be? And how can I scale with mod_wsgi and python.
> 
> Thanks,
> Darshan
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/e800f19c-3946-4749-8464-96364ddba0ccn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/F88CF216-24C5-49DA-9333-CE271AE1FE02%40gmail.com.

Re: [modwsgi] How to authenticate against Django’s user database from Apache

[Graham Dumpleton]

What errors are logged to the Apache error log?

What does the Python code you have added look like?

What does the Apache configuration you have added look like?

Without more information it is hard to guess what the issue may be.

Graham

> On 7 Sep 2023, at 2:21 am, Marcel Müller  wrote:
> 
> Hi, 
> 
> when I follow the documentation I get an 500 Internal Server Error. 
> I want to protect images (uploads by the user) from the public and other 
> users. 
> 
> Everything works until I get to the part like in the subject described. 
> 
> When I follow the documentation like "Finally, edit your WSGI script 
> mysite.wsgi to tie Apache’s authentication to your site’s authentication 
> mechanisms by importing the check_password function:" the provided code gives 
> me the mentioned 500 error and the entire website is not available anymore. 
> When I stick to the default code in wsgi.py it works and the  part 
> works, where I get an apache authentication dialogue.
> But I guess this is not how it is suppose to work. When I type in my 
> credentials the 500 error shows again.
> 
> I am a python/django/apache newbie and I am stuck to this for days now. 
> 
> Any help would be appreciated. 
> 
> Best,
> Marcel
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/b26a327c-00ad-439e-b4c3-f1e171a7e03dn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/9226B44A-0FFD-43DA-B446-8D17F0DF1BF2%40gmail.com.

Re: [modwsgi] modwsgi installation in python 2.7

[Graham Dumpleton]

The Apache distribution you are using is either not 64bit, or is not packaged 
up to include the bits that would allow compilation of Apache extensions 
modules. The latter is quite common with xampp distributions of Apache.

It is strongly recommended you use the Apache Lounge distribution of Apache.

Also, do you really need to use Python 2.7? Python 2.7 hasn't been a supported 
Python version for a very long time.

> On 11 Aug 2023, at 1:11 pm, krishna personal  
> wrote:
> 
> ERROR: Command errored out with exit status 1:
>  command: 'c:\python27\python.exe' -u -c 'import sys, setuptools, 
> tokenize; sys.argv[0] = 
> '"'"'c:\\users\\userid\\appdata\\local\\temp\\4\\pip-install-ufntlw\\mod-wsgi\\setup.py'"'"';
>  
> __file__='"'"'c:\\users\\userid\\appdata\\local\\temp\\4\\pip-install-ufntlw\\mod-wsgi\\setup.py'"'"';f=getattr(tokenize,
>  '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
> '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' 
> install --record 
> 'c:\users\userid\appdata\local\temp\4\pip-record-w2eivs\install-record.txt' 
> --single-version-externally-managed --compile
>  cwd: 
> c:\users\userid\appdata\local\temp\4\pip-install-ufntlw\mod-wsgi\
> Complete output (232 lines):
> running install
> running build
> running build_py
> creating build
> creating build\lib.win-amd64-2.7
> creating build\lib.win-amd64-2.7\mod_wsgi
> copying src\__init__.py -> build\lib.win-amd64-2.7\mod_wsgi
> creating build\lib.win-amd64-2.7\mod_wsgi\server
> copying src\server\apxs_config.py -> 
> build\lib.win-amd64-2.7\mod_wsgi\server
> copying src\server\environ.py -> build\lib.win-amd64-2.7\mod_wsgi\server
> copying src\server\__init__.py -> build\lib.win-amd64-2.7\mod_wsgi\server
> creating build\lib.win-amd64-2.7\mod_wsgi\server\management
> copying src\server\management\__init__.py -> 
> build\lib.win-amd64-2.7\mod_wsgi\server\management
> creating build\lib.win-amd64-2.7\mod_wsgi\server\management\commands
> copying src\server\management\commands\runmodwsgi.py -> 
> build\lib.win-amd64-2.7\mod_wsgi\server\management\commands
> copying src\server\management\commands\__init__.py -> 
> build\lib.win-amd64-2.7\mod_wsgi\server\management\commands
> creating build\lib.win-amd64-2.7\mod_wsgi\docs
> copying docs\_build\html\__init__.py -> 
> build\lib.win-amd64-2.7\mod_wsgi\docs
> creating build\lib.win-amd64-2.7\mod_wsgi\images
> copying images\__init__.py -> build\lib.win-amd64-2.7\mod_wsgi\images
> copying images\snake-whiskey.jpg -> 
> build\lib.win-amd64-2.7\mod_wsgi\images
> running build_ext
> building 'mod_wsgi.server.mod_wsgi' extension
> creating build\temp.win-amd64-2.7
> creating build\temp.win-amd64-2.7\Release
> creating build\temp.win-amd64-2.7\Release\src
> creating build\temp.win-amd64-2.7\Release\src\server
> C:\Users\userid\AppData\Local\Programs\Common\Microsoft\Visual C++ for 
> Python\9.0\VC\Bin\amd64\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG 
> -IC:\xampp\apache/include -Ic:\python27\include -Ic:\python27\PC 
> /Tcsrc/server\mod_wsgi.c 
> /Fobuild\temp.win-amd64-2.7\Release\src/server\mod_wsgi.obj
> mod_wsgi.c
> c:\python27\include\pyconfig.h(344) : warning C4005: 'PLATFORM' : macro 
> redefinition
> c:\xampp\apache\include\os.h(42) : see previous definition of 
> 'PLATFORM'
> src/server\mod_wsgi.c(471) : warning C4267: 'initializing' : conversion 
> from 'size_t' to 'long', possible loss of data
> src/server\mod_wsgi.c(472) : warning C4267: 'initializing' : conversion 
> from 'size_t' to 'long', possible loss of data
> src/server\mod_wsgi.c(580) : warning C4267: '=' : conversion from 
> 'size_t' to 'long', possible loss of data
> src/server\mod_wsgi.c(729) : warning C4267: '=' : conversion from 
> 'size_t' to 'long', possible loss of data
> src/server\mod_wsgi.c(775) : warning C4267: '=' : conversion from 
> 'size_t' to 'long', possible loss of data
> src/server\mod_wsgi.c(1860) : warning C4244: '=' : conversion from 
> 'Py_ssize_t' to 'long', possible loss of data
> src/server\mod_wsgi.c(3480) : warning C4244: '=' : conversion from 
> 'Py_ssize_t' to 'long', possible loss of data
> src/server\mod_wsgi.c(6160) : warning C4244: 'return' : conversion from 
> '__int64' to 'long', possible loss of data
> C:\Users\userid\AppData\Local\Programs\Common\Microsoft\Visual C++ for 
> Python\9.0\VC\Bin\amd64\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG 
> -IC:\xampp\apache/include -Ic:\python27\include -Ic:\python27\PC 
> /Tcsrc/server\wsgi_apache.c 
> /Fobuild\temp.win-amd64-2.7\Release\src/server\wsgi_apache.obj
> wsgi_apache.c
> c:\python27\include\pyconfig.h(344) : warning C4005: 'PLATFORM' : macro 
> redefinition
> c:\xampp\apache\include\os.h(42) : see previous definition of 
> 'PLATFORM'
> C:\Users\userid\AppData\Local\Programs\Common\Microsoft\Vi

Re: [modwsgi] Https for flask deployment

[Graham Dumpleton]

That port 5000 is mentioned makes it look like the HTML code of the page 
requesting the image is hardwiring port 5000. Apache/mod_wsgi shouldn't be 
generating that since it isn't set up to use that port. That or the Flask 
config mentions port 5000 somewhere and that is used in generating URLs.

That said, if a proxy is used in front of Apache/mod_wsgi, it may be worthwhile 
reading:

* http://blog.dscpl.com.au/2015/06/proxying-to-python-web-application.html
* http://blog.dscpl.com.au/2015/07/redirection-problems-when-proxying-to.html

These talks about how to configure mod_wsgi and set up your app so that public 
host and port are properly passed through to mod_wsgi backend and then used by 
your application when generating URLs.

Anyway, see if that gives you any ideas. Grep through your code and see if 5000 
is mentioned anywhere.

Graham

> On 15 May 2023, at 7:57 pm, Babacar Sow  wrote:
> 
> Hi,
> i wrote a website via flask however i am facing a problem. I have a virtual 
> machine that performs a haproxy that redirects givemeasign requests to this 
> virtual machine.
> The flask website is used as a backend for a chrome extension which is 
> supposed to display gifs on a webpage. However, since the website is launched 
> in http mode, I have an error when my extension fetch 
> http://givemeasign.unamurcs.be because the site is in http. if I want to 
> display a gif on an https page then I get an error like this.(see picture)
> 
> For the ha proxy to be done I use docker. Here is the docker file I'm using.
> 
>   # Utilisez une image Python pré-configurée
> FROM python:3.9
> 
> # Installez les dépendances
> COPY requirements.txt /app/requirements.txt
> WORKDIR /app
> # update packages
> RUN apt-get -qq update
> RUN apt-get install --yes apache2 apache2-dev
> RUN pip install mod_wsgiA
> RUN python -m pip install --upgrade pip
> RUN pip install --no-cache-dir -r requirements.txt
> 
> # Copiez le code de votre application Flask dans le conteneur Docker
> COPY . /app
> 
> # Définir la variable d'environnement FLASK_APP
> ENV FLASK_APP=app.py
> ENV FLASK_DEBUG=true
> ENV FLASK_ENV=deployement
> 
> # Exposez le port sur lequel votre application Flask écoute
> EXPOSE 8000
> EXPOSE 443
> # Lancez l'application Flask
> CMD ["sh", "-c", "sleep 5 &&  mod_wsgi-express start-server wsgi.py 
> --https-port 443 --server-name givemeasign.unamurcs.be --ssl-certificate-file 
> cert.pem --ssl-certificate-key-file key.pem --user www-data --group www-data"]
> 
> and here is my docker-compose.yaml file : 
> # creating a volume to be able to persist data between Postgres container 
> restarts
> volumes:
>   users-vol:
> 
> services:
> 
>   pgsql:
> image: postgres:12.11
> restart: always
> environment:
>   POSTGRES_PASSWORD: pwd # environment variable that sets the superuser 
> password for PostgreSQL
>   POSTGRES_USER: usr # variable that will create the specified user
>   POSTGRES_DB: users # the name of your db
> volumes:
>   - users-vol:/var/lib/postgresql/data
> ports:
>   - 5432:5433
> 
>   
>   python:
> build: 
>   context: .
>   dockerfile: ./Dockerfile
> depends_on:
>   - pgsql
> ports:
>   - 8000:8000
>   - 443:443
> 
> 
> 
> When i build the docker, everything is good as you can see in the second 
> picture.
>  
> My problem is that i can access to the http link and everything is work well 
> instead of the error i mentionned before wit the "mixed content" but i can't 
> load the https website and i don't know why. Maybe i made a mistake somewhere 
> 
> I hope that i will find some help here because that's for an exam and 
> everthing is working locally. The only problem is on the the deployment. 
> 
> Kind regards,
> Babacar
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/5327b2d6-f34b-4418-b324-54a6754969c2n%40googlegroups.com
>  
> .
> 

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/5EEB784F-C52E-40EF-943C-DAAB03219DC1%40gmail.com.

Re: [modwsgi] Need help on mod_wsgi module installation in Oracle HTTP Server

[Graham Dumpleton]

General documentation for mod_wsgi can be found at:

https://modwsgi.readthedocs.io/en/master/

Details of using pip to install mod_wsgi can be found at:

https://pypi.org/project/mod-wsgi/
mod-wsgi
pypi.org

Django specific instructions can be found at:

https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/modwsgi/
I can't help you with specific instructions for Oracle Linux. Try searching for 
instructions related to Red Hat Linux or CentOS as I understand Oracle Linux 
uses same packaging system.

Graham

> On 6 May 2023, at 1:10 pm, ramesh pasham  wrote:
> 
> Hi Team,
> I would like to deploy a django application on Oracle HTTP Server using 
> mod_wsgi module.
> 
> I need installation steps how to configure mod_wsgi module in Oracle HTTP 
> Server
> 
> Please help me.
> 
> 
> Thanks,
> Ramesh
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/366d4fe1-4969-413b-8849-ab9726759c3dn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/05C33EB0-35A0-498B-9167-7A5F79157484%40gmail.com.

Re: [modwsgi] Timeout error for flask app

[Graham Dumpleton]

Having to set these timeouts to be very large values is generally indicative of 
a poor design.

For these sorts of long running operations you are usually better of using a 
background task queuing system like Celery to handle running of the job. Your 
front end then just queues the job and polls to see if the task is finished and 
get the response.

In the worst case for these very long running requests a synchronous type web 
system like WSGI may not be a good idea and you are better off using an async 
web server.

That all said, likely what is happening is that because Timeout is 300, the 
Apache child process is giving up on waiting for a response from the mod_wsgi 
daemon process before request-timeout could even kick in.

You can try overriding socket-timeout option on WSGIDaemonProcess to a larger 
value that 300 (inherited from Timeout), but as I said, using large timeouts 
like this is generally not a good idea.

Graham

> On 30 Apr 2023, at 2:27 pm, Aash  wrote:
> 
> I never changed it. It shows 300. Should I make it to 600?
> 
> On Saturday, April 29, 2023 at 9:21:15 PM UTC-7 Graham Dumpleton wrote:
>> What is the Timeout directive set to in your main Apache configuration?
>> 
>> 
>>> On 30 Apr 2023, at 2:18 pm, Aash > wrote:
>>> 
>> 
>>> Hello Graham, Thanks for the quick response.
>>> 
>>> The API response depends on how many items are sent in a batch so for a 
>>> long list it can take a long time (It is taking a list of domains and 
>>> returns a list). I am using the Python Requests library and requests.post 
>>> <http://requests.post/> to call the API. 
>>> This error occurs only when there is a long list which might need a minute 
>>> or two to get response from the API. The error occurs on all the requests 
>>> that are having longer lists. 
>>> 
>>> On Saturday, April 29, 2023 at 9:10:01 PM UTC-7 Graham Dumpleton wrote:
>>>> How long does it usually take for the remote API to respond? Does it 
>>>> always respond quickly, or can it take a very long time? Does this error 
>>>> occur on every request, or only after your web application has been 
>>>> running for a while?
>>>> 
>>>> 
>>>>> On 30 Apr 2023, at 2:04 pm, Aash > wrote:
>>>>> 
>>>> 
>>>>> I am trying to host my Flask app on a Linux server. My app connects to an 
>>>>> API and waits for a response. It is giving me this error.
>>>>> 
>>>>> [Sun Apr 30 05:57:30.091150 2023] [wsgi:error] [pid 524703:tid 
>>>>> 140623501117184] [client someIp:62319] Timeout when reading response 
>>>>> headers from daemon process 'webApp': /var/www/webApp/webapp.wsgi, 
>>>>> referer: http://serverIP/
>>>>> 
>>>>> My conf file looks like this:
>>>>> 
>>>>> 
>>>>> ServerName serverIp
>>>>> ServerAdmin em...@mywebsite.com <>
>>>>> 
>>>>> WSGIDaemonProcess webApp processes=4 threads=5 maximum-requests=1000 
>>>>> request-timeout=600
>>>>> WSGIProcessGroup webApp
>>>>> 
>>>>> WSGIScriptAlias / /var/www/webApp/webapp.wsgi process-group=webApp 
>>>>> application-group=%{GLOBAL}
>>>>> 
>>>>> 
>>>>> Order allow,deny
>>>>> Allow from all
>>>>> 
>>>>> 
>>>>> Alias /static /var/www/webApp/webApp/static
>>>>> 
>>>>> Order allow,deny
>>>>> Allow from all
>>>>> 
>>>>> 
>>>>> ErrorLog ${APACHE_LOG_DIR}/error.log
>>>>> LogLevel warn
>>>>> CustomLog ${APACHE_LOG_DIR}/access.log combined
>>>>> 
>>>>> The error on user-side is 
>>>>> Gateway Timeout
>>>>> The gateway did not receive a timely response from the upstream server or 
>>>>> application.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>>> -- 
>>>>> 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 modwsgi+u...@googlegroups.com <>.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.go

Re: [modwsgi] Timeout error for flask app

[Graham Dumpleton]

What is the Timeout directive set to in your main Apache configuration?

> On 30 Apr 2023, at 2:18 pm, Aash  wrote:
> 
> Hello Graham, Thanks for the quick response.
> 
> The API response depends on how many items are sent in a batch so for a long 
> list it can take a long time (It is taking a list of domains and returns a 
> list). I am using the Python Requests library and requests.post to call the 
> API. 
> This error occurs only when there is a long list which might need a minute or 
> two to get response from the API. The error occurs on all the requests that 
> are having longer lists. 
> 
> On Saturday, April 29, 2023 at 9:10:01 PM UTC-7 Graham Dumpleton wrote:
>> How long does it usually take for the remote API to respond? Does it always 
>> respond quickly, or can it take a very long time? Does this error occur on 
>> every request, or only after your web application has been running for a 
>> while?
>> 
>> 
>>> On 30 Apr 2023, at 2:04 pm, Aash > wrote:
>>> 
>> 
>>> I am trying to host my Flask app on a Linux server. My app connects to an 
>>> API and waits for a response. It is giving me this error.
>>> 
>>> [Sun Apr 30 05:57:30.091150 2023] [wsgi:error] [pid 524703:tid 
>>> 140623501117184] [client someIp:62319] Timeout when reading response 
>>> headers from daemon process 'webApp': /var/www/webApp/webapp.wsgi, referer: 
>>> http://serverIP/
>>> 
>>> My conf file looks like this:
>>> 
>>> 
>>> ServerName serverIp
>>> ServerAdmin em...@mywebsite.com <>
>>> 
>>> WSGIDaemonProcess webApp processes=4 threads=5 maximum-requests=1000 
>>> request-timeout=600
>>> WSGIProcessGroup webApp
>>> 
>>> WSGIScriptAlias / /var/www/webApp/webapp.wsgi process-group=webApp 
>>> application-group=%{GLOBAL}
>>> 
>>> 
>>> Order allow,deny
>>> Allow from all
>>> 
>>> 
>>> Alias /static /var/www/webApp/webApp/static
>>> 
>>> Order allow,deny
>>> Allow from all
>>> 
>>> 
>>> ErrorLog ${APACHE_LOG_DIR}/error.log
>>> LogLevel warn
>>> CustomLog ${APACHE_LOG_DIR}/access.log combined
>>> 
>>> The error on user-side is 
>>> Gateway Timeout
>>> The gateway did not receive a timely response from the upstream server or 
>>> application.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>>> -- 
>>> 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 modwsgi+u...@googlegroups.com <>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/modwsgi/94c43590-df3c-4a93-8cd9-d2afb965a631n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/modwsgi/94c43590-df3c-4a93-8cd9-d2afb965a631n%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 modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/e0bccec9-53a2-41af-a9e5-edcb1229ef80n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/modwsgi/e0bccec9-53a2-41af-a9e5-edcb1229ef80n%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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/681A2942-932F-4756-A888-E8855F8474AB%40gmail.com.

Re: [modwsgi] Timeout error for flask app

[Graham Dumpleton]

How long does it usually take for the remote API to respond? Does it always 
respond quickly, or can it take a very long time? Does this error occur on 
every request, or only after your web application has been running for a while?

> On 30 Apr 2023, at 2:04 pm, Aash  wrote:
> 
> I am trying to host my Flask app on a Linux server. My app connects to an API 
> and waits for a response. It is giving me this error.
> 
> [Sun Apr 30 05:57:30.091150 2023] [wsgi:error] [pid 524703:tid 
> 140623501117184] [client someIp:62319] Timeout when reading response headers 
> from daemon process 'webApp': /var/www/webApp/webapp.wsgi, referer: 
> http://serverIP/
> 
> My conf file looks like this:
> 
> 
> ServerName serverIp
> ServerAdmin em...@mywebsite.com
> 
> WSGIDaemonProcess webApp processes=4 threads=5 maximum-requests=1000 
> request-timeout=600
> WSGIProcessGroup webApp
> 
> WSGIScriptAlias / /var/www/webApp/webapp.wsgi process-group=webApp 
> application-group=%{GLOBAL}
> 
> 
> Order allow,deny
> Allow from all
> 
> 
> Alias /static /var/www/webApp/webApp/static
> 
> Order allow,deny
> Allow from all
> 
> 
> ErrorLog ${APACHE_LOG_DIR}/error.log
> LogLevel warn
> CustomLog ${APACHE_LOG_DIR}/access.log combined
> 
> The error on user-side is 
> Gateway Timeout
> The gateway did not receive a timely response from the upstream server or 
> application.
> 
> 
> 
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/94c43590-df3c-4a93-8cd9-d2afb965a631n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/2ADE1DCE-3FDF-4B6A-8E9A-EBB2AE35AF38%40gmail.com.

Re: [modwsgi] mod_wsgi permission error on activate file

[Graham Dumpleton]

For the database, just make sure not using a relative path to its location. 
Calculate an absolute path as otherwise it placement will be dictated what the 
current working directory Apache runs as, which may not be a desirable 
location. See:

https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#application-working-directory

> On 18 Apr 2023, at 1:09 am, Harald Fontius  wrote:
> 
> Now I removed the virtual environment and change wsgi-file to this:
> 
> and the config file accordingly and the application starts! 
> Now I am struggeling with my sqlite db. Obviously it not enough to just have 
> in the document root like in the test system. If you have a hint for this 
> would be highly recommended! 
> Harald Fontius schrieb am Montag, 17. April 2023 um 14:42:49 UTC+2:
>> Hi Graham, thank you very much for your comments and recommendations. 
>> 
>> 1. I do not have  AppArmor enabled - at least I am not aware of
>> 2. I have checked my installation implementing the suggested test 
>> applicationn "myapp" described here 
>> 
>>  - it worked fine. So the installation seems to be ok. 
>> 3. I haven't  found the file mod_wsgi.so neither with LD_LIBRARY_PATH set 
>> nor without. So I run mod_wsgi-express module-config and received this 
>> answer:
>> LoadModule wsgi_module 
>> "/home/hfwds/.local/lib/python3.10/site-packages/mod_wsgi/server/mod_wsgi-py310.cpython-310-x86_64-linux-gnu.so
>>  "
>> WSGIPythonHome "/usr"
>> what bothers my is that the pyhton home is /user - actually I found 
>> python3.10 here: /usr/local/lib/python3.10 but the wsgi_module seem to be 
>> under /home/hfwds/.local/lib/python3.10/
>> I seem to have 2 different python3.10 installations. Might this be a 
>> problem? BTW: the one under /usr/ is the latest. 
>> 4. I checked your recommendation with the virtual environments. Actually it 
>> seems that I do not necessarily need a virtual environment as I do not plan 
>> to have "multiple distinct Python environments for the same version of 
>> Python," as described here 
>> .
>>  
>> So I just want to run one python application that start with __init__.py 
>> load view.py that holds the logic runing a flask python project installed 
>> here.  
>> 
>> I still struggeling how the wsgi file would look like to  start this. Any 
>> recommendation: Thank you again in advance. 
>> Kind regard from Germany 
>> Harald 
>> 
>> Harald Fontius schrieb am Sonntag, 16. April 2023 um 22:50:42 UTC+2:
>>> I am trying to run a PYTHON FLASK application created in MS Visual Studio 
>>> and exported it to a directory call “conjugationgame”. 
>>> 
>>> In the VISUAL STUDIO environment it runs without problems. Now I want to 
>>> install it on a LINUX Server hosted by IONOS. 
>>> 
>>> UBUNTU  22.04.2 LTS (GNU/Linux 5.15.0-69-generic x86_64) is installed. 
>>> Apache2 is installed and shows this status:
>>> 
>>> apache2.service - The Apache HTTP Server
>>>  Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor 
>>> preset: enabled)
>>>  Active: active (running) since Wed 2023-04-12 15:58:48 UTC; 1 day 23h 
>>> ago
>>>Docs: https://httpd.apache.org/docs/2.4/
>>>Main PID: 15997 (apache2)
>>>   Tasks: 71 (limit: 2193)
>>>  Memory: 30.1M
>>> CPU: 55.237s
>>>  CGroup: /system.slice/apache2.service
>>>  ├─15997 /usr/sbin/apache2 -k start
>>>  ├─75728 /usr/sbin/apache2 -k start
>>>  ├─75729 /usr/sbin/apache2 -k start
>>>  ├─75730 /usr/sbin/apache2 -k start
>>>  └─75731 /usr/sbin/apache2 -k start
>>> 
>>> I tried to install a mod_wsgi virtual environment following @Luke Peter’s 
>>> very good video tutorial (183) How to Deploy a Flask App to Linux (Apache 
>>> and WSGI) - YouTube 
>>> In installed the application like this:
>>> 
>>> 
>>> 
>>> 
>>> I run pipenv install according to this answer to a problem with  
>>> mutablemapping python - AttributeError: module 'collections' has no 
>>> attribute 'MutableMapping' - Stack Overflow 
>>> 
>>>  
>>> 
>>> Although I got an error running  pipenv install after changing the 
>>> directory to var/www/conjugationgame.de/conjugationgame/ 
>>> :
>>> 
>>> 
>>> 
>>> 
>>> Hard to read:
>>> 
>>> PermissionError: [Errno 13] Permission denied 
>>> ‘var/www/conjugationgame.de/conjugationgame/._atomic-writelcmrxftk 
>>> ’ (might 
>>> be the problem but I couldn’t find anything to solve it)
>>> 
>>> pipenv –venv gives the link to the virtual environment:
>>> 
>>> 
>>> 
>>> 
>>>

Re: [modwsgi] mod_wsgi permission error on activate file

[Graham Dumpleton]

Home directories on Linux distributions are often not accessible to other 
users. So changing permissions of directories/files under the home directory 
doesn't help since can't see into the actual home directory. You preferably 
should not stick your project code under a user home directory.

That said, one way around it is to set user/group on WSGIDaemonProcess to owner 
of the home directory, although that is not generally recommended as then your 
code runs as you and not a user with more restricted access. Anyway, you do 
seem to have that, so is a bit strange why that isn't working.

One thing to try in order to work out whether your application is in fact 
running in daemon mode and somehow Apache configuration is not broken is:

https://modwsgi.readthedocs.io/en/master/user-guides/checking-your-installation.html#embedded-or-daemon-mode

The only other thing can think of is you have AppArmor on Ubuntu enabled and 
configured in a way that prevents access to directories/files in that location 
by Apache httpd process. This happens quite a bit with SELinux on Red Hat type 
operating systems, but never run into anyone who actually bothers to run 
AppArmor.

BTW, to initialise virtual environments, it is better to avoid activate_this.py 
if can. See:

https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html

for recommended ways.

Graham

> On 16 Apr 2023, at 10:08 pm, Harald Fontius  wrote:
> 
> I am trying to run a PYTHON FLASK application created in MS Visual Studio and 
> exported it to a directory call “conjugationgame”.
> 
> In the VISUAL STUDIO environment it runs without problems. Now I want to 
> install it on a LINUX Server hosted by IONOS.
> 
> UBUNTU  22.04.2 LTS (GNU/Linux 5.15.0-69-generic x86_64) is installed. 
> Apache2 is installed and shows this status:
> 
> apache2.service - The Apache HTTP Server
>  Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor 
> preset: enabled)
>  Active: active (running) since Wed 2023-04-12 15:58:48 UTC; 1 day 23h ago
>Docs: https://httpd.apache.org/docs/2.4/
>Main PID: 15997 (apache2)
>   Tasks: 71 (limit: 2193)
>  Memory: 30.1M
> CPU: 55.237s
>  CGroup: /system.slice/apache2.service
>  ├─15997 /usr/sbin/apache2 -k start
>  ├─75728 /usr/sbin/apache2 -k start
>  ├─75729 /usr/sbin/apache2 -k start
>  ├─75730 /usr/sbin/apache2 -k start
>  └─75731 /usr/sbin/apache2 -k start
> 
> I tried to install a mod_wsgi virtual environment following @Luke Peter’s 
> very good video tutorial (183) How to Deploy a Flask App to Linux (Apache and 
> WSGI) - YouTube 
> In installed the application like this:
> 
> 
> 
> 
> I run pipenv install according to this answer to a problem with  
> mutablemapping python - AttributeError: module 'collections' has no attribute 
> 'MutableMapping' - Stack Overflow 
> 
>  
> 
> Although I got an error running  pipenv install after changing the directory 
> to var/www/conjugationgame.de/conjugationgame/:
> 
> 
> 
> 
> Hard to read:
> 
> PermissionError: [Errno 13] Permission denied 
> ‘var/www/conjugationgame.de/conjugationgame/._atomic-writelcmrxftk’ (might be 
> the problem but I couldn’t find anything to solve it)
> 
> pipenv –venv gives the link to the virtual environment:
> 
> 
> 
> 
> With this link I created the wsgi file like this:
> 
> 
> 
> 
> and the config file like this
> 
> 
> 
> 
> Checked the syntax of the config and restarted apache2.
> 
> 
> 
> 
> When calling https://conjugationgame.de  I get 
> this error:
> 
> [Fri Apr 14 15:18:59.616298 2023] [wsgi:error] [pid 75730:tid 
> 139907032913472] [client 91.23.91.105:56927] mod_wsgi (pid=75730): Failed to 
> exec Python script file '/var/www/conjugationgame.de/__init__.wsgi'., 
> referer: https://conjugationgame.de/
> 
> [Fri Apr 14 15:18:59.616378 2023] [wsgi:error] [pid 75730:tid 
> 139907032913472] [client 91.23.91.105:56927] mod_wsgi (pid=75730): Exception 
> occurred processing WSGI script '/var/www/conjugationgame.de/__init__.wsgi'., 
> referer: https://conjugationgame.de/
> 
> [Fri Apr 14 15:18:59.616487 2023] [wsgi:error] [pid 75730:tid 
> 139907032913472] [client 91.23.91.105:56927] Traceback (most recent call 
> last):, referer: https://conjugationgame.de/
> 
> [Fri Apr 14 15:18:59.616514 2023] [wsgi:error] [pid 75730:tid 
> 139907032913472] [client 91.23.91.105:56927]   File 
> "/var/www/conjugationgame.de/__init__.wsgi", line 4, in , referer: 
> https://conjugationgame.de/
> 
> [Fri Apr 14 15:18:59.616520 2023] [wsgi:error] [pid 75730:tid 
> 139907032913472] [client 91.23.91.105:56927] with open(activate_this) as 
> file_:, referer: https://conjugationgame.de/
> 
> [Fri Apr 14 15:18:59.616569 2023] [wsgi:error] [pid 75730:tid 
> 1399070329

Re: [modwsgi] Install mod_wsgi error

[Graham Dumpleton]

Depends on how you want to use it.

If you want to install a system package for Apache/mod_wsgi you will need to 
refer to your operating system packaging guides for how to install it. Once you 
have the system package installed, you can manually configure the system Apache 
by following mod_wsgi docs at:

https://www.modwsgi.org 

If you want to use mod_wsgi-express from the command line with Flask, for 
installation see the Flask documentation:

https://flask.palletsprojects.com/en/2.2.x/deploying/mod_wsgi/
and:

https://pypi.org/project/mod-wsgi/
mod-wsgi
pypi.org


Graham


> On 4 Apr 2023, at 1:45 am, 方俊  wrote:
> 
> Hello, how to install mod_wsgi in flask, one of my direct errors, I have 
> installed Apache
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/2e70591b-097e-4408-a35f-ff89613b564fn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/A9258856-5D03-4B62-B16A-8CFDA3A5D897%40gmail.com.

Re: [modwsgi] Failed to fetch jessie packages

[Graham Dumpleton]

Think you may have the wrong list for this. This seems to be a general Debian 
question and not specific to mod_wsgi. Suggest you ask on StackOverflow.

Graham

> On 29 Mar 2023, at 12:07 am, arun krishna  
> wrote:
> 
> while making docker build apt-get update failed with below error
> 
> Err http://deb.debian.org/ jessie/main amd64 Packages
> 404 Not Found
> Err http://deb.debian.org/ jessie-updates/main amd64 Packages
> 404 Not Found
> �[91mW: Failed to fetch 
> http://security.debian.org/dists/jessie/updates/main/binary-amd64/Packages 
> 404 Not Found [IP: 151.101.2.132 80]
> 
> W: Failed to fetch 
> http://deb.debian.org/debian/dists/jessie/main/binary-amd64/Packages 404 Not 
> Found
> 
> W: Failed to fetch 
> http://deb.debian.org/debian/dists/jessie-updates/main/binary-amd64/Packages 
> 404 Not Found
> 
> E: Some index files failed to download. They have been ignored, or old ones 
> used instead.
> �[0mThe command '/bin/sh -c apt-get update && apt-get upgrade -y python-pip 
> && pip install --upgrade pip && apt-get install -y cron bc' returned a 
> non-zero code: 100
> 
> Thanks
> Arun
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/44646edb-4f03-47ad-925d-e1bec34b804bn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/05426147-932A-4A51-953B-1EC28979311A%40gmail.com.

Re: [modwsgi] Timeout when reading response header from daemon process.

[Graham Dumpleton]

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?

Graham

> On 9 Feb 2023, at 7:22 am, Graham Dumpleton  
> wrote:
> 
> 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 ?? () from 
> target:/usr/lib/python3.10/lib-dynload/_sqlite3.cpython-310-x86_64-linux-gnu.so
> #9  0x7f68a750b01a in sqlite3LeaveMutexAndCloseZombie () from 
> target:/lib/x86_64-linux-gnu/libsqlite3.so.0
> 
> Note how that function ends up calling PyGILState_Ensure(). That is a big no 
> no when working with Python sub interpreters.
> 
> In other words, it uses the simplified GIL state API for some callback into 
> Python from C code of SQLite and using that  when in a sub interpreter can 
> cause deadlocks.
> 
> https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#python-simplified-gil-state-api
> 
> So need to find the code for that function in sqlite module and work out what 
> it does.
> 
> Graham
> 
>> On 9 Feb 2023, at 7:09 am, Graham Dumpleton  
>> wrote:
>> 
>> 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 sqlite module.
>> 
>> Graham
>> 
>>> On 9 Feb 2023, at 7:02 am, Carsten Fuchs  wrote:
>>> 
>>> 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 readibility. Please let me know if I should send 
>>> differently instead.)
>>> Between the two "thread apply all bt" commands I waited about two minutes:
>>> 
>>> 
>>> $ sudo gdb /usr/sbin/apache2 60501
>>> GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
>>> Copyright (C) 2022 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later 
>>> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Type "show copying" and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <https://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>>   <http://www.gnu.org/software/gdb/documentation/>.
>>> 
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from /usr/sbin/apache2...
>>> (No debugging symbols found in /usr/sbin/apache2)
>>> Attaching to program: /usr/sbin/apache2, process 60501
>>> [New LWP 60532]
>>> [New LWP 60533]
>>> [New LWP 60534]
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> 0x7f68af72bd7f in __GI___poll (fds=0x7ffe9f0b9e90, nfds=1, timeout=-1) 
>>> at ../sysdeps/unix/sysv/linux/poll.c:29
>>> 29  ../sysdeps/unix/sysv/linux/poll.c: Datei oder Verzeichnis nicht 
>>> gefunden.
>>> (gdb) thread apply all bt
>>> 
>>> Thread 4 (Thread 0x7f68ad6f9640 (LWP 60534) "apache2"):
>>> #0  __futex_abstimed_wait_common64 (private=-1359973880, cancel=true, 
>>> abstime=0x7f68ad6f7220, op=137, expected=0, futex_word=0x7f68af3b49a8 
>>> <_PyRuntime+424>) at ./nptl/futex-internal.c:57
>>> #1  __futex_abstimed_wait_common (cancel=true, private=-1359973880, 
>>> abstime=0x7f68ad6f7220, clockid=-1359689157, expected=0, 
>>> futex_word=0x7f68af3b49a8 <_PyRuntime+424>) at ./np

Re: [modwsgi] Timeout when reading response header from daemon process.

[Graham Dumpleton]

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 ?? () from 
target:/usr/lib/python3.10/lib-dynload/_sqlite3.cpython-310-x86_64-linux-gnu.so
#9  0x7f68a750b01a in sqlite3LeaveMutexAndCloseZombie () from 
target:/lib/x86_64-linux-gnu/libsqlite3.so.0

Note how that function ends up calling PyGILState_Ensure(). That is a big no no 
when working with Python sub interpreters.

In other words, it uses the simplified GIL state API for some callback into 
Python from C code of SQLite and using that  when in a sub interpreter can 
cause deadlocks.

https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#python-simplified-gil-state-api

So need to find the code for that function in sqlite module and work out what 
it does.

Graham

> On 9 Feb 2023, at 7:09 am, Graham Dumpleton  
> wrote:
> 
> 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 sqlite module.
> 
> Graham
> 
>> On 9 Feb 2023, at 7:02 am, Carsten Fuchs  wrote:
>> 
>> 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 readibility. Please let me know if I should send differently 
>> instead.)
>> Between the two "thread apply all bt" commands I waited about two minutes:
>> 
>> 
>> $ sudo gdb /usr/sbin/apache2 60501
>> GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
>> Copyright (C) 2022 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> Type "show copying" and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <https://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>>   <http://www.gnu.org/software/gdb/documentation/>.
>> 
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /usr/sbin/apache2...
>> (No debugging symbols found in /usr/sbin/apache2)
>> Attaching to program: /usr/sbin/apache2, process 60501
>> [New LWP 60532]
>> [New LWP 60533]
>> [New LWP 60534]
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> 0x7f68af72bd7f in __GI___poll (fds=0x7ffe9f0b9e90, nfds=1, timeout=-1) 
>> at ../sysdeps/unix/sysv/linux/poll.c:29
>> 29   ../sysdeps/unix/sysv/linux/poll.c: Datei oder Verzeichnis nicht 
>> gefunden.
>> (gdb) thread apply all bt
>> 
>> Thread 4 (Thread 0x7f68ad6f9640 (LWP 60534) "apache2"):
>> #0  __futex_abstimed_wait_common64 (private=-1359973880, cancel=true, 
>> abstime=0x7f68ad6f7220, op=137, expected=0, futex_word=0x7f68af3b49a8 
>> <_PyRuntime+424>) at ./nptl/futex-internal.c:57
>> #1  __futex_abstimed_wait_common (cancel=true, private=-1359973880, 
>> abstime=0x7f68ad6f7220, clockid=-1359689157, expected=0, 
>> futex_word=0x7f68af3b49a8 <_PyRuntime+424>) at ./nptl/futex-internal.c:87
>> #2  __GI___futex_abstimed_wait_cancelable64 
>> (futex_word=futex_word@entry=0x7f68af3b49a8 <_PyRuntime+424>, 
>> expected=expected@entry=0, clockid=clockid@entry=1, 
>> abstime=abstime@entry=0x7f68ad6f7220, private=private@entry=0) at 
>> ./nptl/futex-internal.c:139
>> #3  0x7f68af6a6f1b in __pthread_cond_wait_common 
>> (abstime=0x7f68ad6f7220, clockid=1, mutex=0x7f68af3b49b0 <_PyRuntime+432>, 
>> cond=0x7f68af3b4980 <_PyRuntime+384>) at ./nptl/pthread_cond_wait.c:503
>> #4  ___pthread_cond_timedwait64 (cond=0x7f68af3b4980 <_PyRuntime+384>, 
>> mutex=0x7f68af3b49b0 <_PyRuntime+432>, abstime=0x7f68ad6f7220) at 
>> ./nptl/pt

Re: [modwsgi] Timeout when reading response header from daemon process.

[Graham Dumpleton]

bpython3.10.so.1.0
> #33 0x7f68aee99458 in _PyEval_EvalFrameDefault () from 
> target:/lib/x86_64-linux-gnu/libpython3.10.so.1.0
> #34 0x7f68aefe781f in ?? () from 
> target:/lib/x86_64-linux-gnu/libpython3.10.so.1.0
> #35 0x7f68aef086ac in ?? () from 
> target:/lib/x86_64-linux-gnu/libpython3.10.so.1.0
> #36 0x7f68af41680f in ?? () from 
> target:/usr/lib/apache2/modules/mod_wsgi.so
> #37 0x7f68af41c9c8 in ?? () from 
> target:/usr/lib/apache2/modules/mod_wsgi.so
> #38 0x7f68af6a7b43 in start_thread (arg=) at 
> ./nptl/pthread_create.c:442
> #39 0x7f68af739a00 in clone3 () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> Thread 3 (Thread 0x7f68adefa640 (LWP 60533) "apache2"):
> #0  __futex_abstimed_wait_common64 (private=0, cancel=true, 
> abstime=0x7f68adef9d80, op=137, expected=0, futex_word=0x7f68af3b49a8 
> <_PyRuntime+424>) at ./nptl/futex-internal.c:57
> #1  __futex_abstimed_wait_common (cancel=true, private=0, 
> abstime=0x7f68adef9d80, clockid=0, expected=0, futex_word=0x7f68af3b49a8 
> <_PyRuntime+424>) at ./nptl/futex-internal.c:87
> #2  __GI___futex_abstimed_wait_cancelable64 
> (futex_word=futex_word@entry=0x7f68af3b49a8 <_PyRuntime+424>, 
> expected=expected@entry=0, clockid=clockid@entry=1, 
> abstime=abstime@entry=0x7f68adef9d80, private=private@entry=0) at 
> ./nptl/futex-internal.c:139
> #3  0x7f68af6a6f1b in __pthread_cond_wait_common (abstime=0x7f68adef9d80, 
> clockid=1, mutex=0x7f68af3b49b0 <_PyRuntime+432>, cond=0x7f68af3b4980 
> <_PyRuntime+384>) at ./nptl/pthread_cond_wait.c:503
> #4  ___pthread_cond_timedwait64 (cond=0x7f68af3b4980 <_PyRuntime+384>, 
> mutex=0x7f68af3b49b0 <_PyRuntime+432>, abstime=0x7f68adef9d80) at 
> ./nptl/pthread_cond_wait.c:652
> #5  0x7f68aefe5df5 in ?? () from 
> target:/lib/x86_64-linux-gnu/libpython3.10.so.1.0
> #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  0x7f68af41cf30 in ?? () from 
> target:/usr/lib/apache2/modules/mod_wsgi.so
> #9  0x7f68af6a7b43 in start_thread (arg=) at 
> ./nptl/pthread_create.c:442
> #10 0x7f68af739a00 in clone3 () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> Thread 2 (Thread 0x7f68ae6fb640 (LWP 60532) "apache2"):
> #0  0x7f68af72e7ed in __GI___select (nfds=0, readfds=0x0, writefds=0x0, 
> exceptfds=0x0, timeout=0x7f68ae6fad60) at 
> ../sysdeps/unix/sysv/linux/select.c:69
> #1  0x7f68af865c09 in apr_sleep () from 
> target:/lib/x86_64-linux-gnu/libapr-1.so.0
> --Type  for more, q to quit, c to continue without paging--
> #2  0x7f68af41d11c in ?? () from 
> target:/usr/lib/apache2/modules/mod_wsgi.so
> #3  0x7f68af6a7b43 in start_thread (arg=) at 
> ./nptl/pthread_create.c:442
> #4  0x7f68af739a00 in clone3 () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> Thread 1 (Thread 0x7f68af59a780 (LWP 60501) "apache2"):
> #0  0x7f68af72bd7f in __GI___poll (fds=0x7ffe9f0b9e90, nfds=1, 
> timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x7f68af85e0fb in apr_poll () from 
> target:/lib/x86_64-linux-gnu/libapr-1.so.0
> #2  0x7f68af4222d8 in ?? () from 
> target:/usr/lib/apache2/modules/mod_wsgi.so
> #3  0x7f68af423f1f in ?? () from 
> target:/usr/lib/apache2/modules/mod_wsgi.so
> #4  0x55c9771cc73d in ap_run_pre_mpm ()
> #5  0x7f68af478455 in ?? () from 
> target:/usr/lib/apache2/modules/mod_mpm_event.so
> #6  0x55c9771c30e8 in ap_run_mpm ()
> #7  0x55c9771c2609 in main ()
> (gdb) 
> 
> 
> Best regards,
> Carsten
> 
> 
> Am 07.02.23 um 22:44 schrieb Graham Dumpleton:
>> 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.
>> 
>> Debugging Techniques — mod_wsgi 4.9.4 documentation 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#debugging-crashes-with-gdb>
>> modwsgi.readthedocs.io 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#debugging-crashes-with-gdb>
>>  favicon.ico 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#debugging-crashes-with-gdb>
>> 
>> <https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#debugging-crashes-with-gdb>
>> 
>> 
>> That may give some clues.
>> 
>> Graham
>> 
>>> On 8 Feb 2023, at 8:42 am, Graham Dumpleton  
>>> wrote:
>>> 
>>> 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
>>> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/a09f8380-eddd-e859-911b-5919d44ea610%40cafu.de.

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/64EC3571-B7F9-4C7F-B3CD-52C1B7E8DD73%40gmail.com.

Re: [modwsgi] Error building on MacOS

[Graham Dumpleton]

As I already said, you can't build Apache httpd from source code yourself on 
macOS. The APR library it uses will not build on macOS and they haven't made a 
release for so many years it has never been fixed. HomeBrew and MacPorts would 
patch it to get it to compile and I am not clear on what the patch is.

Overall I would suggest ditching MacPorts. It has always been inferior to 
HomeBrew and has always caused lots of problems for mod_wsgi because their 
Python distro is often broken and can't build embedded applications properly. 
Seems their Apache httpd is also inferior as well.

Graham

> On 8 Feb 2023, at 5:42 pm, Gnarlodious  wrote:
> 
> There isn't any worker or event module included with the MacPorts Apache, and 
> prefork is compiled in. Meanwhile mod_wsgi is working well enough as it is, 
> maybe sometime later I will try to build a custom Apache.
> 
> Thanks.
> 
> -- Gnarlie
> On Tuesday, February 7, 2023 at 2:53:29 PM UTC-7 Graham Dumpleton wrote:
>> It may have default prefork configured, but you should be able to 
>> dynamically override that through configuration to either worker or event 
>> MPM. The only time you wouldn't is if they static compiled all Apache 
>> modules in, which is not usually done and would be pretty stupid on their 
>> part if they are.
>> 
>> Look for LoadModule mpm_prefork_module line and see if alternatives are 
>> commented out for other MPMs and just change which is used.
>> 
>> Graham
>> 
>> 
>>> On 8 Feb 2023, at 8:48 am, Gnarlodious > wrote:
>>> 
>> 
>>> So I installed the MacPorts mod_wsgi which was pretty simple and works 
>>> well. Unfortunately the MacPorts Apache has the default compiled-in MPM of 
>>> "prefork", which causes my WSGI sessions to expire after about 10 seconds. 
>>> Looks like I will need to download the Apache installer and build it with 
>>> the "worker" MPM to get mod_wsgi to behave like I want.
>>> 
>>> -- Gnarlie
>>> 
>>> On Tuesday, February 7, 2023 at 9:39:34 AM UTC-7 Gnarlodious wrote:
>>>> 
>>>> Okay, it looks like I installed Macports Apache, since Homebrew has given 
>>>> me such trouble in the past. They also have mod_wsgi: 
>>>> https://ports.macports.org/port/mod_wsgi/details/ but it says unverified 
>>>> for ARM64 processor. Will give it a try and report back if it works
>>>> 
>>>> -- Gnarlie
>>>> 
>>>> On Tuesday, February 7, 2023 at 12:09:10 AM UTC-7 Graham Dumpleton wrote:
>>>>> You can't use configure/make/make install (CMMI) method to install on 
>>>>> macOS if is system Apache httpd as Apple supplied Apache httpd is broken. 
>>>>> Installing from upstream Apache httpd source code also will not work. You 
>>>>> need to install Apache httpd using Homebrew and use that instead if want 
>>>>> to use CMMI method.
>>>>> 
>>>>> As to Python, Apple supplied Apache is not under /opt/local so somewhat 
>>>>> doubt that is Xcode version.
>>>>> 
>>>>> Either way, you can try using "pip install mod_wsgi" method instead. See:
>>>>> 
>>>>> 
>>>>> mod-wsgi
>>>>> pypi.org
>>>>>  <https://pypi.org/project/mod-wsgi/>mod-wsgi 
>>>>> <https://pypi.org/project/mod-wsgi/>
>>>>> pypi.org <https://pypi.org/project/mod-wsgi/>
>>>>>  
>>>>> This should work, although do note that latest macOS versions block you 
>>>>> running third party Apache module, so your only choice is to use 
>>>>> mod_wsgi-express instead and you can't manually configure Apache using 
>>>>> the module it builds.
>>>>> 
>>>>> Using HomeBrew Apache avoids the macOS restrictions on third party Apache 
>>>>> modules as well.
>>>>> 
>>>>> Graham
>>>>> 
>>>>> 
>>>>>> On 7 Feb 2023, at 6:00 pm, Gnarlodious > wrote:
>>>>>> 
>>>>> 
>>>>>> I ran:
>>>>>> ./configure --with-python=/opt/local/bin/python 
>>>>>> --with-apxs=/opt/local/bin/apxs
>>>>>> 
>>>>>> ...which points to Python3.9 in Xcode.
>>>>>> 
>>>>>> I said make and got errors at the end with no build file:
>>>>>> ld: warning: directory not found for option 
>>>>>> &#x

Re: [modwsgi] Error building on MacOS

[Graham Dumpleton]

It may have default prefork configured, but you should be able to dynamically 
override that through configuration to either worker or event MPM. The only 
time you wouldn't is if they static compiled all Apache modules in, which is 
not usually done and would be pretty stupid on their part if they are.

Look for LoadModule mpm_prefork_module line and see if alternatives are 
commented out for other MPMs and just change which is used.

Graham

> On 8 Feb 2023, at 8:48 am, Gnarlodious  wrote:
> 
> So I installed the MacPorts mod_wsgi which was pretty simple and works well. 
> Unfortunately the MacPorts Apache has the default compiled-in MPM of 
> "prefork", which causes my WSGI sessions to expire after about 10 seconds. 
> Looks like I will need to download the Apache installer and build it with the 
> "worker" MPM to get mod_wsgi to behave like I want.
> 
> -- Gnarlie
> 
> On Tuesday, February 7, 2023 at 9:39:34 AM UTC-7 Gnarlodious wrote:
>> 
>> Okay, it looks like I installed Macports Apache, since Homebrew has given me 
>> such trouble in the past. They also have mod_wsgi: 
>> https://ports.macports.org/port/mod_wsgi/details/ but it says unverified for 
>> ARM64 processor. Will give it a try and report back if it works
>> 
>> -- Gnarlie
>> 
>> On Tuesday, February 7, 2023 at 12:09:10 AM UTC-7 Graham Dumpleton wrote:
>>> You can't use configure/make/make install (CMMI) method to install on macOS 
>>> if is system Apache httpd as Apple supplied Apache httpd is broken. 
>>> Installing from upstream Apache httpd source code also will not work. You 
>>> need to install Apache httpd using Homebrew and use that instead if want to 
>>> use CMMI method.
>>> 
>>> As to Python, Apple supplied Apache is not under /opt/local so somewhat 
>>> doubt that is Xcode version.
>>> 
>>> Either way, you can try using "pip install mod_wsgi" method instead. See:
>>> 
>>> 
>>> mod-wsgi
>>> pypi.org
>>>  <https://pypi.org/project/mod-wsgi/>mod-wsgi 
>>> <https://pypi.org/project/mod-wsgi/>
>>> pypi.org <https://pypi.org/project/mod-wsgi/>
>>>  
>>> This should work, although do note that latest macOS versions block you 
>>> running third party Apache module, so your only choice is to use 
>>> mod_wsgi-express instead and you can't manually configure Apache using the 
>>> module it builds.
>>> 
>>> Using HomeBrew Apache avoids the macOS restrictions on third party Apache 
>>> modules as well.
>>> 
>>> Graham
>>> 
>>> 
>>>> On 7 Feb 2023, at 6:00 pm, Gnarlodious > wrote:
>>>> 
>>> 
>>>> I ran:
>>>> ./configure --with-python=/opt/local/bin/python 
>>>> --with-apxs=/opt/local/bin/apxs
>>>> 
>>>> ...which points to Python3.9 in Xcode.
>>>> 
>>>> I said make and got errors at the end with no build file:
>>>> ld: warning: directory not found for option 
>>>> '-L/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/config'
>>>> ld: warning: -undefined dynamic_lookup may not work with chained fixups
>>>> 
>>>> There is a folder at
>>>> /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9
>>>> ...but no config folder inside it.
>>>> 
>>>> This is MacOS 13.1
>>>> 
>>>> What's the next step?
>>>> 
>>>> -- Gnarlie
>>>> 
>>> 
>>>> -- 
>>>> 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 modwsgi+u...@googlegroups.com <>.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/modwsgi/b3d3caea-1101-4b3e-9989-484f6ba511e2n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/modwsgi/b3d3caea-1101-4b3e-9989-484f6ba511e2n%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 modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/f9d57376-4d6d-4148-86b9-63c3a30ace14n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/modwsgi/f9d57376-4d6d-4148-86b9-63c3a30ace14n%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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/78565705-CAC6-4175-8231-2DB84CE093B5%40gmail.com.

Re: [modwsgi] Timeout when reading response header from daemon process.

[Graham Dumpleton]

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.

https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#debugging-crashes-with-gdb

That may give some clues.

Graham

> On 8 Feb 2023, at 8:42 am, Graham Dumpleton  
> wrote:
> 
> 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
>> /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 carsten  4096 Feb  6 20:41 dateutil
>> drwxrwxr-x  3 carsten carsten  4096 Feb  6 20:40 _distutils_hack
>> drwxrwxr-x 18 carsten carsten  4096 Feb  6 20:41 django
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 Django-4.1.5.dist-info
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 
>> django_improved_user-2.0a2.dist-info
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 
>> django_widget_tweaks-1.4.12.dist-info
>> drwxrwxr-x  4 carsten carsten  4096 Feb  6 20:41 improved_user
>> drwxrwxr-x  5 carsten carsten  4096 Feb  6 20:40 pip
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:40 pip-22.0.2.dist-info
>> drwxrwxr-x  6 carsten carsten  4096 Feb  6 20:40 pkg_resources
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 __pycache__
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 
>> python_dateutil-2.8.2.dist-info
>> drwxrwxr-x  7 carsten carsten  4096 Feb  6 20:40 setuptools
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:40 setuptools-59.6.0.dist-info
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 six-1.16.0.dist-info
>> drwxrwxr-x  5 carsten carsten  4096 Feb  6 20:41 sqlparse
>> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 sqlparse-0.4.3.dist-info
>> drwxrwxr-x  4 carsten carsten  4096 Feb  6 20:41 widget_tweaks
>> -rw-rw-r--  1 carsten carsten   152 Feb  6 20:40 distutils-precedence.pth
>> -rw-rw-r--  1 carsten carsten 34549 Feb  6 20:41 six.py
>> 
>> $ find -iname "*.so"
>> 
>> The last command returned no output, but I additionally looked into the 
>> directories also in many other ways to make sure that I didn't run a wrong 
>> search. Hmmm.
>> 
>> Best regards,
>> Carsten
>> 
>> 
>> Am 07.02.23 um 00:55 schrieb Graham Dumpleton:
>>> 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 am, Carsten Fuchs  
>>>> <mailto:carsten.fu...@cafu.de> wrote:
>>>> 
>>>> 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 several minutes. However, that never was and still 
>>>> doesn't seem to be a problem: Uploads still succeed, it's only the GET 
>>>> requests that fail. The GET requests in turn do more than just sending 
>>>> some HTML with the image URLs: especially they use the Pillow library to 
>>>> lazily produce thumbnails, put timestamps into the images, etc.
>>>> 
>>>> Therefore I thought that Pillow (9.4.0) might be the culprit, so I removed 
>>>> the related code, made a new virtuelenv without Pillow from scratch and 
>>>> restarted Apache. Unfortunately, it didn't help – please see the error log 
>>>> below. The timeout occurs only after the browser has received a large 
>>>> portion, possibly all, of the view's response.
>>>> 
>>>> `pip list` shows
>>>> 
>>>> Package  Version
>>>>  ---
>>&g

Re: [modwsgi] Timeout when reading response header from daemon process.

[Graham Dumpleton]

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
> /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 carsten  4096 Feb  6 20:41 dateutil
> drwxrwxr-x  3 carsten carsten  4096 Feb  6 20:40 _distutils_hack
> drwxrwxr-x 18 carsten carsten  4096 Feb  6 20:41 django
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 Django-4.1.5.dist-info
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 
> django_improved_user-2.0a2.dist-info
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 
> django_widget_tweaks-1.4.12.dist-info
> drwxrwxr-x  4 carsten carsten  4096 Feb  6 20:41 improved_user
> drwxrwxr-x  5 carsten carsten  4096 Feb  6 20:40 pip
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:40 pip-22.0.2.dist-info
> drwxrwxr-x  6 carsten carsten  4096 Feb  6 20:40 pkg_resources
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 __pycache__
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 
> python_dateutil-2.8.2.dist-info
> drwxrwxr-x  7 carsten carsten  4096 Feb  6 20:40 setuptools
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:40 setuptools-59.6.0.dist-info
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 six-1.16.0.dist-info
> drwxrwxr-x  5 carsten carsten  4096 Feb  6 20:41 sqlparse
> drwxrwxr-x  2 carsten carsten  4096 Feb  6 20:41 sqlparse-0.4.3.dist-info
> drwxrwxr-x  4 carsten carsten  4096 Feb  6 20:41 widget_tweaks
> -rw-rw-r--  1 carsten carsten   152 Feb  6 20:40 distutils-precedence.pth
> -rw-rw-r--  1 carsten carsten 34549 Feb  6 20:41 six.py
> 
> $ find -iname "*.so"
> 
> The last command returned no output, but I additionally looked into the 
> directories also in many other ways to make sure that I didn't run a wrong 
> search. Hmmm.
> 
> Best regards,
> Carsten
> 
> 
> Am 07.02.23 um 00:55 schrieb Graham Dumpleton:
>> 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 am, Carsten Fuchs  
>>> <mailto:carsten.fu...@cafu.de> wrote:
>>> 
>>> 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 several minutes. However, that never was and still 
>>> doesn't seem to be a problem: Uploads still succeed, it's only the GET 
>>> requests that fail. The GET requests in turn do more than just sending some 
>>> HTML with the image URLs: especially they use the Pillow library to lazily 
>>> produce thumbnails, put timestamps into the images, etc.
>>> 
>>> Therefore I thought that Pillow (9.4.0) might be the culprit, so I removed 
>>> the related code, made a new virtuelenv without Pillow from scratch and 
>>> restarted Apache. Unfortunately, it didn't help – please see the error log 
>>> below. The timeout occurs only after the browser has received a large 
>>> portion, possibly all, of the view's response.
>>> 
>>> `pip list` shows
>>> 
>>> Package  Version
>>>  ---
>>> asgiref  3.6.0
>>> Django   4.1.5
>>> django-improved-user 2.0a2
>>> django-widget-tweaks 1.4.12
>>> pip  22.0.2
>>> python-dateutil  2.8.2
>>> setuptools   59.6.0
>>> six  1.16.0
>>> sqlparse 0.4.3
>>> 
>>> 
>>> Is any of these know for causing problems like numpy?
>>> 
>>> Best regards,
>>> Carsten
>>> 
>>> The above mentioned error log:
>>> 
>>> [Mon Feb 06 20:52:20.329545 2023] [mpm_event:notice] [pid 25844:tid 
>>> 140714434877312] AH00489: Apache/2.4.52 (Ubuntu) mod_wsgi/4.9.0 Python/3.10 
>>> configured -- resuming normal operations
>>&g

Re: [modwsgi] Error building on MacOS

[Graham Dumpleton]

You can't use configure/make/make install (CMMI) method to install on macOS if 
is system Apache httpd as Apple supplied Apache httpd is broken. Installing 
from upstream Apache httpd source code also will not work. You need to install 
Apache httpd using Homebrew and use that instead if want to use CMMI method.

As to Python, Apple supplied Apache is not under /opt/local so somewhat doubt 
that is Xcode version.

Either way, you can try using "pip install mod_wsgi" method instead. See:

https://pypi.org/project/mod-wsgi/
mod-wsgi
pypi.org
 
This should work, although do note that latest macOS versions block you running 
third party Apache module, so your only choice is to use mod_wsgi-express 
instead and you can't manually configure Apache using the module it builds.

Using HomeBrew Apache avoids the macOS restrictions on third party Apache 
modules as well.

Graham

> On 7 Feb 2023, at 6:00 pm, Gnarlodious  wrote:
> 
> I ran:
> ./configure --with-python=/opt/local/bin/python 
> --with-apxs=/opt/local/bin/apxs
> 
> ...which points to Python3.9 in Xcode.
> 
> I said make and got errors at the end with no build file:
> ld: warning: directory not found for option 
> '-L/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/config'
> ld: warning: -undefined dynamic_lookup may not work with chained fixups
> 
> There is a folder at
> /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9
> ...but no config folder inside it.
> 
> This is MacOS 13.1
> 
> What's the next step?
> 
> -- Gnarlie
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/b3d3caea-1101-4b3e-9989-484f6ba511e2n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/424F7E5A-FE2D-4236-B2C4-86120BE06077%40gmail.com.

Re: [modwsgi] Timeout when reading response header from daemon process.

[Graham Dumpleton]

[pid 25977:tid 140714434877312] 
> mod_wsgi (pid=25977): Adding '/home/carsten/HallCam/web' to path.
> [Mon Feb 06 21:00:01.811479 2023] [wsgi:info] [pid 25846:tid 140714360796736] 
> mod_wsgi (pid=25846): Create interpreter '192.168.1.222:32228|'.
> [Mon Feb 06 21:00:01.824795 2023] [wsgi:info] [pid 25846:tid 140714360796736] 
> mod_wsgi (pid=25846): Adding '/home/carsten/HallCam/web' to path.
> [Mon Feb 06 21:00:01.825535 2023] [wsgi:info] [pid 25846:tid 140714360796736] 
> [remote 37.81.109.237:49942] mod_wsgi (pid=25846, process='cf-hallcam-site', 
> application='192.168.1.222:32228|'): Loading Python script file 
> '/home/carsten/HallCam/web/HallCam/wsgi.py'.
> [Mon Feb 06 21:00:02.506063 2023] [wsgi:info] [pid 25977:tid 140714402760256] 
> mod_wsgi (pid=25977): Create interpreter '192.168.1.222:32228|'.
> [Mon Feb 06 21:00:02.519453 2023] [wsgi:info] [pid 25977:tid 140714402760256] 
> mod_wsgi (pid=25977): Adding '/home/carsten/HallCam/web' to path.
> [Mon Feb 06 21:00:02.520239 2023] [wsgi:info] [pid 25977:tid 140714402760256] 
> [remote 88.75.25.178:43650] mod_wsgi (pid=25977, process='cf-hallcam-site', 
> application='192.168.1.222:32228|'): Loading Python script file 
> '/home/carsten/HallCam/web/HallCam/wsgi.py'.
> [Mon Feb 06 21:00:03.299821 2023] [core:info] [pid 25847:tid 140714151155264] 
> [client 88.75.25.178:43652] AH00128: File does not exist: 
> /var/www/HallCam-media/thumbs/camera-2/pic_20230206_205532_4.jpg, 
> referer: http://vdzuggmrroo5k7e9.myfritz.net:32228/
> [Mon Feb 06 21:05:02.996169 2023] [wsgi:info] [pid 25977:tid 140714419545664] 
> mod_wsgi (pid=25977): Daemon process deadlock timer expired, stopping process 
> 'cf-hallcam-site'.
> [Mon Feb 06 21:05:02.996308 2023] [wsgi:info] [pid 25977:tid 140714434877312] 
> mod_wsgi (pid=25977): Shutdown requested 'cf-hallcam-site'.
> [Mon Feb 06 21:05:07.996544 2023] [wsgi:info] [pid 25977:tid 140714177934912] 
> mod_wsgi (pid=25977): Aborting process 'cf-hallcam-site'.
> [Mon Feb 06 21:05:07.996587 2023] [wsgi:info] [pid 25977:tid 140714177934912] 
> mod_wsgi (pid=25977): Exiting process 'cf-hallcam-site'.
> [Mon Feb 06 21:05:08.002106 2023] [wsgi:error] [pid 25848:tid 
> 140713647920704] [client 37.81.109.237:49944] Truncated or oversized response 
> headers received from daemon process 'cf-hallcam-site': 
> /home/carsten/HallCam/web/HallCam/wsgi.py
> [Mon Feb 06 21:05:08.002137 2023] [wsgi:error] [pid 25848:tid 
> 140714025395776] (104)Connection reset by peer: [client 88.75.25.178:43650] 
> mod_wsgi (pid=25848): Failed to proxy response from daemon., referer: 
> http://vdzuggmrroo5k7e9.myfritz.net:32228/
> [Mon Feb 06 21:05:09.015715 2023] [wsgi:info] [pid 26028:tid 140714434877312] 
> mod_wsgi (pid=26028): Attach interpreter ''.
> [Mon Feb 06 21:05:09.027591 2023] [wsgi:info] [pid 26028:tid 140714434877312] 
> mod_wsgi (pid=26028): Adding '/home/carsten/HallCam/web' to path.
> [Mon Feb 06 21:05:29.082057 2023] [wsgi:info] [pid 25846:tid 140714419545664] 
> mod_wsgi (pid=25846): Daemon process deadlock timer expired, stopping process 
> 'cf-hallcam-site'.
> [Mon Feb 06 21:05:29.082193 2023] [wsgi:info] [pid 25846:tid 140714434877312] 
> mod_wsgi (pid=25846): Shutdown requested 'cf-hallcam-site'.
> [Mon Feb 06 21:05:34.082447 2023] [wsgi:info] [pid 25846:tid 140714177934912] 
> mod_wsgi (pid=25846): Aborting process 'cf-hallcam-site'.
> [Mon Feb 06 21:05:34.082493 2023] [wsgi:info] [pid 25846:tid 140714177934912] 
> mod_wsgi (pid=25846): Exiting process 'cf-hallcam-site'.
> [Mon Feb 06 21:05:35.038614 2023] [wsgi:info] [pid 26047:tid 140714434877312] 
> mod_wsgi (pid=26047): Attach interpreter ''.
> [Mon Feb 06 21:05:35.050453 2023] [wsgi:info] [pid 26047:tid 140714434877312] 
> mod_wsgi (pid=26047): Adding '/home/carsten/HallCam/web' to path.
> 
> 
> 
> 
> 
> Am 05.02.23 um 23:32 schrieb Graham Dumpleton:
>> 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 up to the issue.
>> 
>> By default the deadlock timeout is 300 seconds.
>> 
>> deadlock-timeout=sss
>> Defines the maximum number of seconds allowed to pass before the daemon 
>> process is shutdown and restarted after a potential deadlock on the Python 
>> GIL has been detected. The defau

Re: [modwsgi] Timeout when reading response header from daemon process.

[Graham Dumpleton]

] 
> (104)Connection reset by peer: [client 88.75.25.178:48210] mod_wsgi 
> (pid=639): Failed to proxy response from daemon., referer: 
> http://vdzuggmrroo5k7e9.myfritz.net:32228/
> [Sun Feb 05 17:23:42.997522 2023] [wsgi:info] [pid 906:tid 140277991982976] 
> mod_wsgi (pid=906): Attach interpreter ''.
> [Sun Feb 05 17:23:43.039478 2023] [wsgi:info] [pid 906:tid 140277991982976] 
> mod_wsgi (pid=906): Adding '/home/carsten/HallCam/web' to path.
> [Sun Feb 05 17:25:01.761551 2023] [wsgi:info] [pid 885:tid 140277959865920] 
> mod_wsgi (pid=885): Create interpreter '192.168.1.222:32228|'.
> [Sun Feb 05 17:25:01.774488 2023] [wsgi:info] [pid 885:tid 140277959865920] 
> mod_wsgi (pid=885): Adding '/home/carsten/HallCam/web' to path.
> [Sun Feb 05 17:25:01.775225 2023] [wsgi:info] [pid 885:tid 140277959865920] 
> [remote 37.81.109.237:49338] mod_wsgi (pid=885, process='cf-hallcam-site', 
> application='192.168.1.222:32228|'): Loading Python script file 
> '/home/carsten/HallCam/web/HallCam/wsgi.py'.
> [Sun Feb 05 17:25:03.155261 2023] [wsgi:error] [pid 885:tid 140277959865920] 
> [remote 37.81.109.237:49338] Picture saved to 
> /var/www/HallCam-media/pictures/camera-1/pic_20230205_172500_4.jpg 
> (image/jpeg, 896262 bytes, camera camera-1)
> [Sun Feb 05 17:30:03.323110 2023] [wsgi:info] [pid 885:tid 140277976651328] 
> mod_wsgi (pid=885): Daemon process deadlock timer expired, stopping process 
> 'cf-hallcam-site'.
> [Sun Feb 05 17:30:03.323253 2023] [wsgi:info] [pid 885:tid 140277991982976] 
> mod_wsgi (pid=885): Shutdown requested 'cf-hallcam-site'.
> 
> 
> Carsten Fuchs schrieb am Sonntag, 5. Februar 2023 um 17:23:29 UTC+1:
>> 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
>>>> modwsgi.readthedocs.io
>>>> 
>>>>  
>>>> <https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#python-simplified-gil-state-api>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>
>>>>
>>>> <https://modwsgi.readthedocs.io/en/master/user-guides/application-issues.html#python-simplified-gil-state-api>
>

Re: [modwsgi] Timeout when reading response header from daemon process.

[Graham Dumpleton]

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.

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  wrote:
> 
> It keeps timing out and I've been trying to solve it to no avail.
> Here my modwsgi.conf
> 
> 
>   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
> 
>   
> 
> Order allow,deny
> Allow from all
> 
> = 2.3>
> Require all granted
> 
>   
>   
> 
>   Alias /static ${project_path}/static
>   
>  Require all granted
>  SetHandler None
>  FileETag none
>  Options FollowSymLinks
>   
> 
>   Alias /media ${project_path}/media
>   
>  Require all granted
>  SetHandler None
>  FileETag none
>  Options FollowSymLinks
>  ErrorDocument 404 /error404
>   
> 
>   ErrorLog /var/log/httpd/${user}-${project_name}-error.log
>   LogLevel info
>   CustomLog /var/log/httpd/${user}-${project_name}-access.log combined
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/02fb2171-ca59-4053-9be3-8ff75e9cf9edn%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/23758818-6AB0-4FBB-903E-AF251D51655D%40gmail.com.

Re: [modwsgi] wsgi: module not found 'django' error when deploying via apache

[Graham Dumpleton]

> On 30 Dec 2022, at 4:34 am, Sam Johnson  wrote:
> 
> I have been trying forever to get my django api to deploy correctly via 
> apache on my new ec2 instance running amazon linux 2. I have installed 
> python3-mod_wsgi.x86_64 and my venv is using python 3.7.15. Trying to go to 
> my django app url I am getting a 500 error. The server runs fine locally.
> 
> I have imported python3-mod_wsgi.x86_64 in my httpd.conf file via:
> LoadModule wsgi_module /etc/httpd/modules/python3-mod_wsgi.x86_64.so
> 
> I am pretty new to this set up, happy to provide any additional info needed.
> 
> Error log shows:
> [Tue Dec 20 21:31:30.690951 2022] [:error] [pid 19216] /usr
> [Tue Dec 20 21:31:30.691287 2022] [:error] [pid 19216] mod_wsgi (pid=19216): 
> Target WSGI script '.../project/project/wsgi.py' cannot be loaded as Python 
> module. 
> [Tue Dec 20 21:31:30.691323 2022] [:error] [pid 19216] mod_wsgi (pid=19216): 
> Exception occurred processing WSGI script '.../project/project/wsgi.py'.
> [Tue Dec 20 21:31:30.691393 2022] [:error] [pid 19216] Traceback (most recent 
> call last): 
> [Tue Dec 20 21:31:30.691423 2022] [:error] [pid 19216] File 
> ".../project/project/wsgi.py", line 19, in  
> [Tue Dec 20 21:31:30.691428 2022] [:error] [pid 19216] from django.core.wsgi 
> import get_wsgi_application 
> [Tue Dec 20 21:31:30.691444 2022] [:error] [pid 19216] ModuleNotFoundError: 
> No module named 'django' 
> [Tue Dec 20 21:31:51.190670 2022] [:error] [pid 19217] 3.7.15 (default, Oct 
> 31 2022, 22:44:31) [Tue Dec 20 21:31:51.190707 2022] [:error] [pid 19217] 
> [GCC 7.3.1 20180712 (Red Hat 7.3.1-15)]
> 
> 
> My apache conf file:
>  
> ServerName api.project.com 
> DocumentRoot path/to/project/root 
> WSGIScriptAlias / /path/to/wsgi.py WSGIDaemonProcess project-name processes=4 
> threads=1 display-name=%{GROUP} 
> python-path=path/to/lib/python3.7/site-packages:/path/to/project/root 
> WSGIProcessGroup project-group

For a start this is wrong in a number of ways. Try with:

WSGIDaemonProcess project-name processes=4 threads=1 display-name=%{GROUP} 
python-home=/path/to/venv python-path=/path/to/project/root
WSGIScriptAlias / /path/to/wsgi.py process-group=project-name 
application-group=%{GLOBAL}

You should not be setting python-path to be the site-packages directory for a 
virtual environment, you should use python-home and set it to the root of the 
virtual environment.

Set process-group on WSGIScriptAlias instead of using WSGIProcessGroup as 
avoids some issues. You didn't have a matching name either way.

Also do tests in:

https://modwsgi.readthedocs.io/en/master/user-guides/checking-your-installation.html#python-installation-in-use

to ensure mod_wsgi is actually using the Python version you think it is.

Also read:

https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html

where it explains how to configure things for a virtual environment.

Also suggest you add:

   WSGIRestrictEmbedded On

outside of any VirtualHost to disable Python in Apache child processes so only 
enabled in mod_wsgi daemon processes.


>  
> Require all granted 
>  
> #SSL stuff... 
> 
> 
> my wsgi.py file:
> 
> 
> I think I originally had the wrong mod_wsgi installed (built for python2). I 
> removed that and installed python3-mod_wsgi.x86_64. 
> 
> I then realized that my mod_wsgi was for python version 3.7, but my 
> application venv was running python 3.6.8. I then wiped the venv and created 
> a new one with python 3.7.15. Changed the conf path to the correct 3.7 
> site-packages (my venv). Still same error
> 
> Would appreciate any help with this, and again, happy to provide more info if 
> needed.
> 
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/d6358f22-e749-4f55-a9e6-6bf5310076d7n%40googlegroups.com
>  
> .
> 

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/7258CEC2-B88E-4D13-8C9C-8B3A3BEB9457%40gmail.com.

Re: [modwsgi] Trouble accessing static files via url in browser

[Graham Dumpleton]

Do note that those entries will only apply when you use:

https://www.nuv2.com:7080/google6821620603f54cd0.html 
<https://www.nuv2.com/google6821620603f54cd0.html> 

with a port since you have it inside of a VirtualHost for that port.



Graham

> On 24 Dec 2022, at 5:44 am, Bob Floyd  wrote:
> 
> PPS If I remove the Alias for the google file from 000-default.conf the 
> browser still loads the file at   
> https://www.nuv2.com/static/content/google6821620603f54cd0.html so am I 
> correct to say the alias isn't doing anything?
> 
> On Friday, December 23, 2022 at 10:37:26 AM UTC-8 Bob Floyd wrote:
>> PS. Interesting, if I navigate to 
>> https://www.nuv2.com/static/content/google6821620603f54cd0.html in the 
>> browser I get the file. I got the idea by noticing in the apache logs that 
>> asking from html had static/content in the url.  Hope this gives you some 
>> guidance as to what I've done wrong!
>> 
>> On Friday, December 23, 2022 at 9:59:32 AM UTC-8 Bob Floyd wrote:
>>> I tried and still get 404:
>>> Alias /google6821620603f54cd0.html 
>>> /home/nuvroot/WWWsiteServer/static/content/google6821620603f54cd0.html
>>> and confirmed the file is there:
>>> ls /home/nuvroot/WWWsiteServer/static/content/google6821620603f54cd0.html
>>> and restarted apache:
>>> sudo /etc/init.d/apache2 restart
>>> 
>>> If you navigate to nuv2.com <http://nuv2.com/> you will see .ico and .jpg 
>>> files in static/content loaded correctly, so I conclude the directory is 
>>> reachable. It's only when I navigate in the browser to 
>>> https:/nuv2.com/google6821620603f54cd0.html 
>>> <http://nuv2.com/google6821620603f54cd0.html> that I consistently get 404. 
>>> It is as if 
>>> WSGIScriptAlias / /var/www/wsgi/WWWsiteServer.wsgi
>>> is being used to process the url (and there is no python route for it) 
>>> instead of
>>> Alias /google6821620603f54cd0.html 
>>> /home/nuvroot/WWWsiteServer/static/content/google6821620603f54cd0.html
>>> but that doesn't make sense as the .ico and .jpg files load (but they also 
>>> get 404 if navigated to). Something is different in asking for the files 
>>> from within html code and asking for them in the browser url.
>>> 
>>> I see this in the error log after I enter 
>>> https:/nuv2.com/google6821620603f54cd0.html 
>>> <http://nuv2.com/google6821620603f54cd0.html> in hte browser:
>>> 
>>> 2022-12-23 17:56:40
>>> Error
>>> 192.88.134.10
>>> 404
>>> GET /google6821620603f54cd0.html 
>>> <https://50.62.181.212/smb/file-manager/code-editor?currentDir=%2Fhttpdocs%2F&subscriptionId=1&file=google6821620603f54cd0.html&redirect=%2Fsmb%2Flog-file%2Fbrowser%2Fid%2F1>
>>>  HTTP/1.0
>>> 
>>> Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like 
>>> Gecko) Chrome/108.0.0.0 <http://108.0.0.0/> Safari/537.36 Edg/108.0.1462.54
>>> 2.30 K
>>> Apache SSL/TLS access
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thursday, December 22, 2022 at 5:51:30 PM UTC-8 Graham Dumpleton wrote:
>>>> Did you try with:
>>>> 
>>>> Alias /google6821620603f54cd0.html 
>>>> /home/nuvroot/WWWsiteServer/static/content/google6821620603f54cd0.html
>>>> 
>>>> or not?
>>>> 
>>>> I wasn't using "/home/google6821620603f54cd0.html" on the Alias line, you 
>>>> were, and I was telling you to change it to the live above. It should look 
>>>> similar to other Alias lines for other files in that directory you already 
>>>> have but you were missing the "WWWsiteServer/static/content" part of the 
>>>> path.
>>>> 
>>>> Graham
>>>> 
>>>> 
>>>>> On 23 Dec 2022, at 12:45 pm, Bob Floyd > wrote:
>>>>> 
>>>> 
>>>>> Hi Graham,
>>>>> 
>>>>> $ ls -lasd /home/nuvroot
>>>>> 4 drwxr-xr-x 6 nuvroot nuvroot 4096 Dec 22 15:54 /home/nuvroot
>>>>> 
>>>>> What I tried didn't work, however I'm also bit confused about your use of 
>>>>> /home/google6821620603f54cd0.html on the Alias line. As that is the 
>>>>> target should the google file also be located there? I don't have access 
>>>>> above nuvroot!
>>>>> 
>>>>> Here is the VirtualHost ( I also co

Re: [modwsgi] Trouble accessing static files via url in browser

[Graham Dumpleton]

Did you try with:

Alias /google6821620603f54cd0.html 
/home/nuvroot/WWWsiteServer/static/content/google6821620603f54cd0.html

or not?

I wasn't using "/home/google6821620603f54cd0.html" on the Alias line, you were, 
and I was telling you to change it to the live above. It should look similar to 
other Alias lines for other files in that directory you already have but you 
were missing the "WWWsiteServer/static/content" part of the path.

Graham

> On 23 Dec 2022, at 12:45 pm, Bob Floyd  wrote:
> 
> Hi Graham,
> 
> $ ls -lasd /home/nuvroot
> 4 drwxr-xr-x 6 nuvroot nuvroot 4096 Dec 22 15:54 /home/nuvroot
> 
> What I tried didn't work, however I'm also bit confused about your use of 
> /home/google6821620603f54cd0.html on the Alias line. As that is the target 
> should the google file also be located there? I don't have access above 
> nuvroot!
> 
> Here is the VirtualHost ( I also copied the google file to /home/nuvroot):
> 
> # Highest priority
> 
> 
> ServerName www.nuv2.com
> 
> ServerAdmin webmaster@localhost
> 
> DocumentRoot /home/nuvroot/WWWsiteServer
> 
> 
> Require all granted
> 
> 
>  WSGIDaemonProcess nuv2.com python-home=/usr/local/venvs/WWWsiteServer
> WSGIProcessGroup nuv2.com
> 
> WSGIApplicationGroup %{GLOBAL}
> 
>WSGIScriptAlias / /var/www/wsgi/WWWsiteServer.wsgi
> 
> 
> Require all granted
> 
> 
>   Alias /BSIM-5-Stage-Inverter.JPG 
> /home/nuvroot/WWWsiteServer/static/content/BSIM-5-Stage-Inverter.JPG
> Alias /Lease.pdf   /home/nuvroot/WWWsiteServer/static/content/Lease.pdf
> Alias /NuV2.ico   /home/nuvroot/WWWsiteServer/static/content/NuV2.ico
> Alias /favicon.ico   
> /home/nuvroot/WWWsiteServer/static/content/favicon.ico
> Alias /PDF_32.png /home/nuvroot/WWWsiteServer/static/content/PDF_32.png
> Alias /SecureLeaseSm.JPG 
> /home/nuvroot/WWWsiteServer/static/content/SecureLeaseSm.JPG
> Alias /TrademarkSmall.JPG 
> /home/nuvroot/WWWsiteServer/static/content/TrademarkSmall.JPG
> Alias /UIDialog.bmp 
> /home/nuvroot/WWWsiteServer/static/content/UIDialog.bmp
> # For google search ownership verification
> Alias /google6821620603f54cd0.html 
> /home/nuvroot/google6821620603f54cd0.html
> # I also tried
> #Alias /google6821620603f54cd0.html /home/google6821620603f54cd0.html
> 
> ErrorLog ${APACHE_LOG_DIR}/error.log
> CustomLog ${APACHE_LOG_DIR}/access.log combined
> 
>   
> 
> Thanks,
> Bob
> On Thursday, December 22, 2022 at 2:31:19 PM UTC-8 Graham Dumpleton wrote:
>> You use "/home/google6821620603f54cd0.html" as the target of the URL path 
>> where it should be:
>> 
>> Alias /google6821620603f54cd0.html 
>> /home/nuvroot/WWWsiteServer/static/content/google6821620603f54cd0.html
>> 
>> based on what directory you said it was in.
>> 
>> If that still doesn't work then the issue may be that the Apache user 
>> doesn't have access to anything under the home directory. So it still 
>> getting access error what do you get for:
>> 
>> ls -lasd /home/nuvroot
>> 
>> Graham
>> 
>> 
>>> On 23 Dec 2022, at 3:46 am, Bob Floyd > wrote:
>>> 
>> 
>>> I put the google search HTML file (for ownership verification) in 
>>> static/content:
>>> 
>>> ~/WWWsiteServer/static/content$ ls -l
>>> total 244
>>> -rw-rw-r-- 1 nuvroot nuvroot 21748 Dec  6 23:53 BSIM-5-Stage-Inverter.JPG
>>> -rw-rw-r-- 1 nuvroot nuvroot 89457 Dec  6 23:53 Lease.pdf
>>> -rw-rw-r-- 1 nuvroot nuvroot  1078 Dec  6 23:53 NuV2.ico
>>> -rw-rw-r-- 1 nuvroot nuvroot   772 Dec  6 23:53 PDF_32.png
>>> -rw-rw-r-- 1 nuvroot nuvroot 27452 Dec  6 23:53 SecureLeaseSm.JPG
>>> -rw-rw-r-- 1 nuvroot nuvroot  8767 Dec  6 23:53 TrademarkSmall.JPG
>>> -rw-rw-r-- 1 nuvroot nuvroot 77494 Dec  6 23:53 UIDialog.bmp
>>> -rw-rw-r-- 1 nuvroot nuvroot  1078 Dec  9 19:19 favicon.ico
>>> -r--r--r-- 1 nuvroot root   53 Dec 22 01:06 google6821620603f54cd0.html
>>> 
>>> In my browser I enter https://www.nuv2.com/google6821620603f54cd0.html as 
>>> recommended by google to test for access to the file and get 404 error.
>>> 
>>> If you navigate to nuv2.com <http://nuv2.com/>, the other files in content 
>>> are properly loaded, although attempting to access any of them using a url 
>>> in the browser also gives 404.
>>> 
>>> In the Apache 000-default.conf file I'm using Alias as recommended in the 
>>> modwsgi docs:
>>> # Remap URL&

Re: [modwsgi] Trouble accessing static files via url in browser

[Graham Dumpleton]

You use "/home/google6821620603f54cd0.html" as the target of the URL path where 
it should be:

Alias /google6821620603f54cd0.html 
/home/nuvroot/WWWsiteServer/static/content/google6821620603f54cd0.html

based on what directory you said it was in.

If that still doesn't work then the issue may be that the Apache user doesn't 
have access to anything under the home directory. So it still getting access 
error what do you get for:

ls -lasd /home/nuvroot

Graham

> On 23 Dec 2022, at 3:46 am, Bob Floyd  wrote:
> 
> I put the google search HTML file (for ownership verification) in 
> static/content:
> 
> ~/WWWsiteServer/static/content$ ls -l
> total 244
> -rw-rw-r-- 1 nuvroot nuvroot 21748 Dec  6 23:53 BSIM-5-Stage-Inverter.JPG
> -rw-rw-r-- 1 nuvroot nuvroot 89457 Dec  6 23:53 Lease.pdf
> -rw-rw-r-- 1 nuvroot nuvroot  1078 Dec  6 23:53 NuV2.ico
> -rw-rw-r-- 1 nuvroot nuvroot   772 Dec  6 23:53 PDF_32.png
> -rw-rw-r-- 1 nuvroot nuvroot 27452 Dec  6 23:53 SecureLeaseSm.JPG
> -rw-rw-r-- 1 nuvroot nuvroot  8767 Dec  6 23:53 TrademarkSmall.JPG
> -rw-rw-r-- 1 nuvroot nuvroot 77494 Dec  6 23:53 UIDialog.bmp
> -rw-rw-r-- 1 nuvroot nuvroot  1078 Dec  9 19:19 favicon.ico
> -r--r--r-- 1 nuvroot root   53 Dec 22 01:06 google6821620603f54cd0.html
> 
> In my browser I enter https://www.nuv2.com/google6821620603f54cd0.html as 
> recommended by google to test for access to the file and get 404 error.
> 
> If you navigate to nuv2.com, the other files in content are properly loaded, 
> although attempting to access any of them using a url in the browser also 
> gives 404.
> 
> In the Apache 000-default.conf file I'm using Alias as recommended in the 
> modwsgi docs:
> # Remap URL's for static files to where they actually are
> Alias /BSIM-5-Stage-Inverter.JPG 
> /home/nuvroot/WWWsiteServer/static/content/BSIM-5-Stage-Inverter.JPG
> Alias /Lease.pdf   /home/nuvroot/WWWsiteServer/static/content/Lease.pdf
> Alias /NuV2.ico   /home/nuvroot/WWWsiteServer/static/content/NuV2.ico
> Alias /favicon.ico   
> /home/nuvroot/WWWsiteServer/static/content/favicon.ico
> Alias /PDF_32.png /home/nuvroot/WWWsiteServer/static/content/PDF_32.png
> Alias /SecureLeaseSm.JPG 
> /home/nuvroot/WWWsiteServer/static/content/SecureLeaseSm.JPG
> Alias /TrademarkSmall.JPG 
> /home/nuvroot/WWWsiteServer/static/content/TrademarkSmall.JPG
> Alias /UIDialog.bmp 
> /home/nuvroot/WWWsiteServer/static/content/UIDialog.bmp
> # For google search ownership verification
> Alias /google6821620603f54cd0.html /home/google6821620603f54cd0.html
> 
> Any suggestions how I can get access to the google html file from the url? 
> It's probably something simple but I've tried a ton of things without success.
> 
> Thanks
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/d69e7b2d-bf4f-417c-847e-0a66bd821d62n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/11EFB49F-01BC-46B3-B503-179D55F2DFB0%40gmail.com.

[modwsgi] Re: configure: error: Apache tool 'apxs' or 'apxs2' is required to build mod_wsgi but httpd24-httpd-devel.x86_64 is installed

[Graham Dumpleton]

Red Hat SCL packages are not installed in standard locations. You have to 
add the bin directory for the specific Red Hat SCL package to your PATH, or 
when configuring/building mod_wsgi supply the --with-apxs option to tell it 
where the "apxs" or "apxs2" script is installed. I don't remember where 
they install SCL packages, so use the commands:

find / -name apxs
find / -name apxs2

to try and find the command.

Sorry for the slow reply, been travelling the last couple of weeks.

Graham

On Monday, 12 December 2022 at 21:27:50 UTC+9 nana...@gmail.com wrote:

> Hello,
>
> On Redhat 7.9 server we have currently runnign Python 3.8 with wsgi.
> I wanted to install also Python 3.10 and I build it from source. Then 
> tried to install mod_wsgi by using pip but got the below error:
> RuntimeError: The 'apxs' command appears not to be installed or is not 
> executable. Please check the list of prerequisites in the documentation for 
> this package and install any missing Apache httpd server packages
>
> I tired also to build it from source but got again the same error:
> ./configure
> checking for apxs2... no
> checking for apxs... no
> configure: error: Apache tool 'apxs' or 'apxs2' is required to build 
> mod_wsgi.
>
> As you can see httpd24-httpd and httpd24-httpd-devel are already installed 
> and also tried to reinstall them (previous version of mod_wsgi was also 
> succesfully installed)
> yum list httpd24-httpd*
> Loaded plugins: langpacks, product-id, search-disabled-repos, 
> subscription-manager
> Installed Packages
> httpd24-httpd.x86_642.4.34-23.el7.5@rhel-server-rhscl-7-rpms
> httpd24-httpd-devel.x86_642.4.34-23.el7.5@rhel-server-rhscl-7-rpms
> httpd24-httpd-tools.x86_642.4.34-23.el7.5@rhel-server-rhscl-7-rpms
> Available Packages
> httpd24-httpd-manual.noarch2.4.34-23.el7.5rhel-server-rhscl-7-rpms
>
> I used following commands in order to build python 3.10
> yum update
> yum install openssl-devel bzip2-devel libffi-devel
> --install openssl 1.1.1 from source (/usr/include/openssl)
> yum remove openssl openssl-devel.x86_64
> unzip openssl-OpenSSL_1_1_1-stable.zip
> cd openssl-OpenSSL_1_1_1-stable/
> ./config --prefix=/usr/include/openssl/
> make
> make install
> wget 
> https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/o/openssl11-libs-1.1.1k-4.el7.x86_64.rpm
> yum install ./openssl11-libs-1.1.1k-4.el7.x86_64.rpm
> /usr/include/openssl/bin/openssl version  --> OpenSSL 1.1.1t-dev  xx XXX 
>  (Library: OpenSSL 1.1.1k  FIPS 25 Mar 2021)
>
> --Install Python 3.10 from source:
> cd
> wget https://www.python.org/ftp/python/3.10.8/Python-3.10.8.tgz
> tar -xzf Python-3.10.8.tgz
> cd Python-3.10.8
> make clean
> ./configure --enable-optimizations --with-openssl=/usr/include/openssl
> make altinstall
>
> Do you have any idea what could be wrong?
>
> Thank you in advance,
> Nadia
>

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/62c7d152-02de-474b-aa74-8b118faa8971n%40googlegroups.com.

Re: [modwsgi] Random segfaults of quiescent mod_wsgi processes

[Graham Dumpleton]

Enabling capture of core dump files and then using gdb to work out where C 
level stack trace is for when process is crashing is all I can think of.

> On 31 Oct 2022, at 7:38 am, stuart mcgraw  wrote:
> 
> Thanks for the vhost suggestion.  I hadn't thought of that but it turned out 
> we didn't need to.
> 
> After more testing it turns out that a .wsgi script with simple hello world 
> script per
> 
>   
> https://modwsgi.readthedocs.io/en/develop/user-guides/quick-configuration-guide.html#wsgi-application-script-file
> 
> is exhibiting the problem: with no incoming requests at all the mod_wsgi 
> process after sitting there for anywhere from a few minutes to a few hours, 
> dies with a segmentation fault.  Any idea what else I could look at?
> On Wednesday, October 26, 2022 at 12:10:38 AM UTC-6 Graham Dumpleton wrote:
> The LogLevel can be set just in a VirtualHost context if is under separate 
> host. If you are then using separate log files for differential VirtualHost 
> it should at least be semi segmented from everything else.
> 
>> On 26 Oct 2022, at 4:34 pm, stuart mcgraw > > wrote:
>> 
>> 
> 
>> I was grepping all the log files for any messages within a minute or two 
>> before the segfaults so if a request was logged anywhere I should have seen 
>> it.  
>> 
>> I'll mention the LogLevel Debug setting to them, but there were complaints 
>> before that LogLevel Info was too noisy so I'm not sure that will fly.
>> 
>> I'll look into the possibility of errant app threads and post back if 
>> anything turns up.  Thanks very much for your help with this.
>> On Tuesday, October 25, 2022 at 11:05:28 PM UTC-6 Graham Dumpleton wrote:
>> The only way I can think of that you may get a request which wasn't logged, 
>> is if an internal Apache request was triggered via an internal redirect from 
>> another Apache module. There still has to be an original request, but it 
>> would be logged as different request URL to where it got internally 
>> redirected.
>> 
>> Since you are using mod_wsgi daemon mode you can likely see better evidence 
>> of all requests being handled if turn on verbose debugging mode, but would 
>> be quite noisy.
>> 
>> LogLevel debug
>> WSGIVerboseDebugging On
>> 
>> Graham
>> 
>> 
>>> On 26 Oct 2022, at 3:33 pm, stuart mcgraw > wrote:
>>> 
>> 
>>> I didn't compile mod_wsgi myself so I can't say 100% but the person who did 
>>> said so and there is a source directory on the machine named mod_wsgi-4.9.4 
>>> with a mod_wsgi.so file whose sha1 checksum matches that of the file in the 
>>> apache modules/ directory, so I'd say I'm 99.9% sure.
>>> 
>>> But the chances of >1Gi requests being made seem pretty small.  The urls 
>>> haven't been publicized, there are only a handful of known users accessing 
>>> the urls infrequently as testers and nothing in the application would 
>>> generate requests of that magnitude.
>>> 
>>> This may be out of scope for you, but are you aware of any (reasonably 
>>> normal) circumstances under which a mod_wsgi process could receive a 
>>> request that wasn't logged by Apache?  Or perhaps I could modify the 
>>> mod_wsgi source code to print a message to a file when a request was 
>>> received (which I could then correlate with the Apache logs to answer the 
>>> question.)  Because usage is very light and this is only for short term 
>>> debugging, I don't think locking or anything fancy would be needed?
>>> 
>>> And I am still wondering about library mismatches or conflicts since 
>>> Apache, Python, mod_wsgi and C-based Python modules (eg psyocopg2) used by 
>>> the app were all built from source.  It is possible that some version 
>>> mismatch there causes some memory corruption that is later manifest when 
>>> one of the mod_wsgi housekeeping threads runs?  I would like if possible to 
>>> rule this out or at least put at the bottom of the list.  
>>> On Tuesday, October 25, 2022 at 8:35:07 PM UTC-6 Graham Dumpleton wrote:
>>> I know you said you were using mod_wsgi/4.9.4, but are you absolutely sure? 
>>>  Apache/2.4.54 made a breaking change by changing the default for 
>>> LimitRequestBody directive, which would cause mod_wsgi daemon process to 
>>> crash when there were sent large request bodies over 1Gi. This was fixed in 
>>> version 4.9.4, but am wondering whether your production system has older 
>>> version than your development s

Re: [modwsgi] Logging with multiple processes

[Graham Dumpleton]

> On 28 Oct 2022, at 2:27 am, Steve  wrote:
> 
> Hi Graham, thanks for your response.
> Sorry I wasn't specific enough, I am logging to a single log file using the 
> WatchedFileHandler to avoid issues with log file creation and rotation.
> As I understand, writing to a single file from multiple processes could cause 
> logs getting mixed up if two processes write at the same time, I couldn't 
> replicate it though. I believe that the same could happen if I log to stderr. 
> I couldn't find if Apache uses some coordination mechanism for outputting the 
> stderr streams of multiple processes to a single Apache error log file.
> 
> I am going to log to stderr as it seems to be working for most people but do 
> you know of any documentation on how Apache handles this? Haven't found any 
> and I would like to read up on it

You would have you dig through Apache source as well as the separate Apache 
Runtime library.

The code basically boils down to:

static void write_logline(char *errstr, apr_size_t len, apr_file_t *logf,
  int level)
{
/* NULL if we are logging to syslog */
if (logf) {
/* Truncate for the terminator (as apr_snprintf does) */
if (len > MAX_STRING_LEN - sizeof(APR_EOL_STR)) {
len = MAX_STRING_LEN - sizeof(APR_EOL_STR);
}
strcpy(errstr + len, APR_EOL_STR);
apr_file_puts(errstr, logf);
apr_file_flush(logf);
}
#ifdef HAVE_SYSLOG
else {
syslog(level < LOG_PRIMASK ? level : APLOG_DEBUG, "%.*s",
   (int)len, errstr);
}
#endif
}

So uses apr_file_puts() followed by a flush.

So perhaps relying on some aspect of OS that when a write is done as a single 
string it avoids interleaving.

Do be aware that Apache caps individual log messages at about 8000 bytes. If 
you can't loose log message content beyond that, you shouldn't rely on Apache 
logging.

Depending on your requirements, you may be better off using log event capture 
using services such as Sentry.

Graham

> 
> On Wednesday, 26 October 2022 at 17:56:10 UTC-3 Graham Dumpleton wrote:
> Most people would just log to stdout/stderr which means log output gets 
> routed into the Apache error log files. Apache's mechanism for handling log 
> files when multiple processes are present seems to work fine. If you have 
> multiple sites on the Apache server then configure Apache to use different 
> log files for each VirtualHost as a way of keeping log files for different 
> application separate.
> 
> Is there a specific reason you are using Python logging system mechanisms to 
> write to distinct log files (if that is what you meant you are doing)?
> 
> Note that most issues with using a single log file for multiple processes 
> revolve around initial log file creation and log file rotation. In Apache log 
> files are initially created from the parent process so there is no race 
> condition on creation. It has a means to handle log file rotation as well, 
> although many Linux systems rely on log rotate service instead.
> 
> Graham
> 
> 
>> On 27 Oct 2022, at 5:50 am, Steve > > wrote:
>> 
> 
>> Hi, I am running a Flask app using mod_wsgi and I've been logging to a file. 
>> The issue is now I need to run it using multiple processes but multiple 
>> processes logging to a file without coordination is not a good idea.
>> 
>> Has anyone heard of a success case where they log to stderr with multiple 
>> processes? That's the approach that I am hoping to take as other approaches 
>> seem too overkill as of right now because they require to spin up some 
>> service independent of the Flask app to handle the logs. 
>> 
>> And another question, does mod_wsgi do something special with opened files 
>> with multiple processes? As I have tested logging with multiple processes to 
>> the same file and have not found any issues.
>> 
>> Thanks!
>> 
>> 
>> 
> 
>> -- 
>> 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 modwsgi+u...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/71b85a03-2818-4492-bbe2-b61344746948n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/71b85a03-2818-4492-bbe2-b61344746948n%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, sen

Re: [modwsgi] Logging with multiple processes

[Graham Dumpleton]

Most people would just log to stdout/stderr which means log output gets routed 
into the Apache error log files. Apache's mechanism for handling log files when 
multiple processes are present seems to work fine. If you have multiple sites 
on the Apache server then configure Apache to use different log files for each 
VirtualHost as a way of keeping log files for different application separate.

Is there a specific reason you are using Python logging system mechanisms to 
write to distinct log files (if that is what you meant you are doing)?

Note that most issues with using a single log file for multiple processes 
revolve around initial log file creation and log file rotation. In Apache log 
files are initially created from the parent process so there is no race 
condition on creation. It has a means to handle log file rotation as well, 
although many Linux systems rely on log rotate service instead.

Graham

> On 27 Oct 2022, at 5:50 am, Steve  wrote:
> 
> Hi, I am running a Flask app using mod_wsgi and I've been logging to a file. 
> The issue is now I need to run it using multiple processes but multiple 
> processes logging to a file without coordination is not a good idea.
> 
> Has anyone heard of a success case where they log to stderr with multiple 
> processes? That's the approach that I am hoping to take as other approaches 
> seem too overkill as of right now because they require to spin up some 
> service independent of the Flask app to handle the logs. 
> 
> And another question, does mod_wsgi do something special with opened files 
> with multiple processes? As I have tested logging with multiple processes to 
> the same file and have not found any issues.
> 
> Thanks!
> 
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/71b85a03-2818-4492-bbe2-b61344746948n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/7A72BF3E-C59C-4706-852D-41DD58F80323%40gmail.com.

Re: [modwsgi] Random segfaults of quiescent mod_wsgi processes

[Graham Dumpleton]

The LogLevel can be set just in a VirtualHost context if is under separate 
host. If you are then using separate log files for differential VirtualHost it 
should at least be semi segmented from everything else.

> On 26 Oct 2022, at 4:34 pm, stuart mcgraw  wrote:
> 
> 
> I was grepping all the log files for any messages within a minute or two 
> before the segfaults so if a request was logged anywhere I should have seen 
> it.  
> 
> I'll mention the LogLevel Debug setting to them, but there were complaints 
> before that LogLevel Info was too noisy so I'm not sure that will fly.
> 
> I'll look into the possibility of errant app threads and post back if 
> anything turns up.  Thanks very much for your help with this.
>> On Tuesday, October 25, 2022 at 11:05:28 PM UTC-6 Graham Dumpleton wrote:
>> The only way I can think of that you may get a request which wasn't logged, 
>> is if an internal Apache request was triggered via an internal redirect from 
>> another Apache module. There still has to be an original request, but it 
>> would be logged as different request URL to where it got internally 
>> redirected.
>> 
>> Since you are using mod_wsgi daemon mode you can likely see better evidence 
>> of all requests being handled if turn on verbose debugging mode, but would 
>> be quite noisy.
>> 
>> LogLevel debug
>> WSGIVerboseDebugging On
>> 
>> Graham
>> 
>>>> On 26 Oct 2022, at 3:33 pm, stuart mcgraw  wrote:
>>>> 
>>> I didn't compile mod_wsgi myself so I can't say 100% but the person who did 
>>> said so and there is a source directory on the machine named mod_wsgi-4.9.4 
>>> with a mod_wsgi.so file whose sha1 checksum matches that of the file in the 
>>> apache modules/ directory, so I'd say I'm 99.9% sure.
>>> 
>>> But the chances of >1Gi requests being made seem pretty small.  The urls 
>>> haven't been publicized, there are only a handful of known users accessing 
>>> the urls infrequently as testers and nothing in the application would 
>>> generate requests of that magnitude.
>>> 
>>> This may be out of scope for you, but are you aware of any (reasonably 
>>> normal) circumstances under which a mod_wsgi process could receive a 
>>> request that wasn't logged by Apache?  Or perhaps I could modify the 
>>> mod_wsgi source code to print a message to a file when a request was 
>>> received (which I could then correlate with the Apache logs to answer the 
>>> question.)  Because usage is very light and this is only for short term 
>>> debugging, I don't think locking or anything fancy would be needed?
>>> 
>>> And I am still wondering about library mismatches or conflicts since 
>>> Apache, Python, mod_wsgi and C-based Python modules (eg psyocopg2) used by 
>>> the app were all built from source.  It is possible that some version 
>>> mismatch there causes some memory corruption that is later manifest when 
>>> one of the mod_wsgi housekeeping threads runs?  I would like if possible to 
>>> rule this out or at least put at the bottom of the list.  
>>>> On Tuesday, October 25, 2022 at 8:35:07 PM UTC-6 Graham Dumpleton wrote:
>>>> I know you said you were using mod_wsgi/4.9.4, but are you absolutely 
>>>> sure?  Apache/2.4.54 made a breaking change by changing the default for 
>>>> LimitRequestBody directive, which would cause mod_wsgi daemon process to 
>>>> crash when there were sent large request bodies over 1Gi. This was fixed 
>>>> in version 4.9.4, but am wondering whether your production system has 
>>>> older version than your development systems use and you just aren't aware 
>>>> of that.
>>>> 
>>>> https://modwsgi.readthedocs.io/en/master/release-notes/version-4.9.4.html#bugs-fixed
>>>> 
>>>> As to back ground threads, mod_wsgi has a couple of background threads 
>>>> which check for idle activity, deadlocks and things, but they touch so 
>>>> little they have never caused issues in the past. Beyond that, the request 
>>>> handler threads themselves should be stuck on a select loop if no requests 
>>>> are happening.
>>>> 
>>>>>> On 26 Oct 2022, at 1:12 pm, stuart mcgraw  wrote:
>>>>>> 
>>>>> Again, thanks for those suggestions.
>>>>> 
>>>>> The OOM killer seems not to be an issue.  I've been told there are no 
>>>>> signs of it in the system logs and

Re: [modwsgi] Random segfaults of quiescent mod_wsgi processes

[Graham Dumpleton]

The only way I can think of that you may get a request which wasn't logged, is 
if an internal Apache request was triggered via an internal redirect from 
another Apache module. There still has to be an original request, but it would 
be logged as different request URL to where it got internally redirected.

Since you are using mod_wsgi daemon mode you can likely see better evidence of 
all requests being handled if turn on verbose debugging mode, but would be 
quite noisy.

LogLevel debug
WSGIVerboseDebugging On

Graham

> On 26 Oct 2022, at 3:33 pm, stuart mcgraw  wrote:
> 
> I didn't compile mod_wsgi myself so I can't say 100% but the person who did 
> said so and there is a source directory on the machine named mod_wsgi-4.9.4 
> with a mod_wsgi.so file whose sha1 checksum matches that of the file in the 
> apache modules/ directory, so I'd say I'm 99.9% sure.
> 
> But the chances of >1Gi requests being made seem pretty small.  The urls 
> haven't been publicized, there are only a handful of known users accessing 
> the urls infrequently as testers and nothing in the application would 
> generate requests of that magnitude.
> 
> This may be out of scope for you, but are you aware of any (reasonably 
> normal) circumstances under which a mod_wsgi process could receive a request 
> that wasn't logged by Apache?  Or perhaps I could modify the mod_wsgi source 
> code to print a message to a file when a request was received (which I could 
> then correlate with the Apache logs to answer the question.)  Because usage 
> is very light and this is only for short term debugging, I don't think 
> locking or anything fancy would be needed?
> 
> And I am still wondering about library mismatches or conflicts since Apache, 
> Python, mod_wsgi and C-based Python modules (eg psyocopg2) used by the app 
> were all built from source.  It is possible that some version mismatch there 
> causes some memory corruption that is later manifest when one of the mod_wsgi 
> housekeeping threads runs?  I would like if possible to rule this out or at 
> least put at the bottom of the list.  
> On Tuesday, October 25, 2022 at 8:35:07 PM UTC-6 Graham Dumpleton wrote:
> I know you said you were using mod_wsgi/4.9.4, but are you absolutely sure?  
> Apache/2.4.54 made a breaking change by changing the default for 
> LimitRequestBody directive, which would cause mod_wsgi daemon process to 
> crash when there were sent large request bodies over 1Gi. This was fixed in 
> version 4.9.4, but am wondering whether your production system has older 
> version than your development systems use and you just aren't aware of that.
> 
> https://modwsgi.readthedocs.io/en/master/release-notes/version-4.9.4.html#bugs-fixed
>  
> <https://modwsgi.readthedocs.io/en/master/release-notes/version-4.9.4.html#bugs-fixed>
> 
> As to back ground threads, mod_wsgi has a couple of background threads which 
> check for idle activity, deadlocks and things, but they touch so little they 
> have never caused issues in the past. Beyond that, the request handler 
> threads themselves should be stuck on a select loop if no requests are 
> happening.
> 
> 
>> On 26 Oct 2022, at 1:12 pm, stuart mcgraw > > wrote:
>> 
> 
>> Again, thanks for those suggestions.
>> 
>> The OOM killer seems not to be an issue.  I've been told there are no signs 
>> of it in the system logs and no signs of memory problems via monitoring 
>> during nomal operations.
>> 
>> Nor did "WSGIDestroyInterpreter Off" have any effect, the segfaults are 
>> still occurring after that was added and Apache restarted.
>> 
>> My understanding of how mod_wsgi works is pretty sketchy.  IIUC you are 
>> saying that the mod_wsgi processes are sitting there, waiting on a select() 
>> call or the like, to receive a request from the mod_wsgi code within Apache; 
>> and in that state they cannot simply spontaneously crash -- it must be that 
>> either that the process received request from Apache (via the mod_wsgi 
>> module) or there is some independent thread running in the Python part of 
>> the mod_wsgi process (which is running my wsgi app) that is causing the 
>> crash?
>> 
>> I based my claim that there were no requests coincidental with the segfaults 
>> based on the lack of log messages within a second or two for some of the 
>> segfaults.  (Its a moderately busy server so of course there were also some 
>> close in time but for seemingly unrelated pages: eg, python, php or c cgi, 
>> or html.)  Is it possible that the mod_wsgi processes are getting woken up 
>> by something that does not produce an apache access log entry?
>> 
>

Re: [modwsgi] Random segfaults of quiescent mod_wsgi processes

[Graham Dumpleton]

I know you said you were using mod_wsgi/4.9.4, but are you absolutely sure?  
Apache/2.4.54 made a breaking change by changing the default for 
LimitRequestBody directive, which would cause mod_wsgi daemon process to crash 
when there were sent large request bodies over 1Gi. This was fixed in version 
4.9.4, but am wondering whether your production system has older version than 
your development systems use and you just aren't aware of that.

https://modwsgi.readthedocs.io/en/master/release-notes/version-4.9.4.html#bugs-fixed

As to back ground threads, mod_wsgi has a couple of background threads which 
check for idle activity, deadlocks and things, but they touch so little they 
have never caused issues in the past. Beyond that, the request handler threads 
themselves should be stuck on a select loop if no requests are happening.

> On 26 Oct 2022, at 1:12 pm, stuart mcgraw  wrote:
> 
> Again, thanks for those suggestions.
> 
> The OOM killer seems not to be an issue.  I've been told there are no signs 
> of it in the system logs and no signs of memory problems via monitoring 
> during nomal operations.
> 
> Nor did "WSGIDestroyInterpreter Off" have any effect, the segfaults are still 
> occurring after that was added and Apache restarted.
> 
> My understanding of how mod_wsgi works is pretty sketchy.  IIUC you are 
> saying that the mod_wsgi processes are sitting there, waiting on a select() 
> call or the like, to receive a request from the mod_wsgi code within Apache; 
> and in that state they cannot simply spontaneously crash -- it must be that 
> either that the process received request from Apache (via the mod_wsgi 
> module) or there is some independent thread running in the Python part of the 
> mod_wsgi process (which is running my wsgi app) that is causing the crash?
> 
> I based my claim that there were no requests coincidental with the segfaults 
> based on the lack of log messages within a second or two for some of the 
> segfaults.  (Its a moderately busy server so of course there were also some 
> close in time but for seemingly unrelated pages: eg, python, php or c cgi, or 
> html.)  Is it possible that the mod_wsgi processes are getting woken up by 
> something that does not produce an apache access log entry?
> 
> I'm still working on the python thread hypothesis (this is a production 
> server so changes aren't easy.)
> On Sunday, October 23, 2022 at 2:12:02 PM UTC-6 Graham Dumpleton wrote:
> How much memory do the processes use? Maybe the system OOM process killer is 
> killing the processes as they consume lots of memory and the system thinks it 
> is running low. There were some potential problems introduced with Python 3.9 
> with how process are shutdown and that causes embedded systems to fail on 
> shutdown.
> 
> See:
> 
> https://modwsgi.readthedocs.io/en/master/release-notes/version-4.9.1.html#features-changed
>  
> <https://modwsgi.readthedocs.io/en/master/release-notes/version-4.9.1.html#features-changed>
> 
> You can try setting:
> 
> WSGIDestroyInterpreter Off
> 
> as mentioned in those change notes and see if it goes away.
> 
> Other than that, if you are confident that no new requests are arriving, can 
> only suggest you work out if there are background threads running in Python.
> 
> You can do that be adding code as described in:
> 
> https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#extracting-python-stack-traces
>  
> <https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#extracting-python-stack-traces>
> 
> and triggering a dump of running threads by touching a file in the file 
> system.
> 
> It might also be helpful if you can work out how to have the system preserve 
> core dumps from Apache so they can be used to extract a true process stack 
> trace as that may give a clue.
> 
> Graham
> 
> 
>> On 24 Oct 2022, at 3:51 am, stuart mcgraw > > wrote:
>> 
> 
>> Thanks for that suggestion.  I passed it on to the site admin made and he 
>> made the "application-group=%{GLOBAL}" change, but unfortunately it made no 
>> difference, the segfaults are still occurring as before.  Is there anything 
>> else I can look at?  The current configuration is:
>> 
>> WSGIDaemonProcess jmwsgi processes=2 threads=10 \
>> display-name=apache2-jmwsgi locale=en_US.UTF-8 lang=en_US.UTF-8
>> WSGIScriptAlias /jmwsgi /usr/local/apache2/jmdictdb/wsgifiles/jmdictdb.wsgi \
>> process-group=jmwsgi application-group=%{GLOBAL}
>> 
>> Would changing to "process=N threads=1" or "processes=1 threads=N" provide 
>> any useful info?  Apache, mod_wsgi and the other web server comp

Re: [modwsgi] HOWTO: configure apache with UserDir and WSGI

[Graham Dumpleton]

What happens if you use:

os.environ["DASH_URL_BASE_PATHNAME"] = '/~mec/dash101/app.wsgi'

> On 22 Oct 2022, at 7:44 pm, Malcolm Cook  wrote:
> 
> On Friday, October 21, 2022 at 3:23:00 AM UTC-5 Graham Dumpleton wrote:
> 
>> On 21 Oct 2022, at 6:40 pm, Malcolm Cook > > wrote:
>> 
>> Hello,
>> 
>> I have configured apache2 for running any .wsgi apps out of ~/public_html 
>> 
>> It works for a simple ~/public_html/hello_world.wsgi
>> 
>> Hooray!
>> 
>> However, I am having trouble when my app uses
>> 
>> /usr/bin/python3 -m venv venv
>> 
>> with the simplest of dash apps.
>> 
>> I have so far learned to include in my app.wsgi the following:
>> 
>> site.addsitedir('/home/mec/public_html/dash101/dash101.wsgi')
> 
> The site.addsitedir() function accepts a directory, not a file. For working 
> with virtual environments ensure you read 
> 
> 
> https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html
>  
> <https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html>
> 
>  
> Apologies - for some bad reason I edited the message after copy-pasting.  I 
> had read your fine documentation and followed its advice only failed to share 
> correct details. 
>  
>> allowing the app to find the dash modules installed into its venv when run 
>> under apache mod_wsgi.
>> 
>> The app now works from the command line; when run under apache mod_wsgi it 
>> only successfully finds the modules in the venv but then fails with:
>> 
>> [root@hd1991356yb mec]# [Fri Oct 21 01:04:29.974555 2022] [wsgi:info] [pid 
>> 69391] mod_wsgi (pid=69391): Create interpreter 
>> 'hd1991356yb.sgc.loc|/~mec/dash101/app.wsgi'.
>> [Fri Oct 21 01:04:29.989457 2022] [wsgi:info] [pid 69391] [client 
>> 10.2.20.25:41124 <http://10.2.20.25:41124/>] mod_wsgi (pid=69391, 
>> process='', application='hd1991356yb.sgc.loc|/~mec/dash101/app.wsgi'): 
>> Loading Python script file '/home/mec/public_html/dash101/app.wsgi'., 
>> referer: http://hd1991356yb/~mec/dash101/ <http://hd1991356yb/~mec/dash101/>
>> [Fri Oct 21 01:04:30.891229 2022] [wsgi:error] [pid 69391] 
>> /home/mec/public_html/dash101/app.py:2: UserWarning:
>> [Fri Oct 21 01:04:30.891279 2022] [wsgi:error] [pid 69391] The 
>> dash_html_components package is deprecated. Please replace
>> [Fri Oct 21 01:04:30.891289 2022] [wsgi:error] [pid 69391] `import 
>> dash_html_components as html` with `from dash import html`
>> [Fri Oct 21 01:04:30.891298 2022] [wsgi:error] [pid 69391]   import 
>> dash_html_components as html
>> [Fri Oct 21 01:04:33.661364 2022] [wsgi:error] [pid 69391] 
>> /home/mec/public_html/dash101/app.py:4: UserWarning:
>> [Fri Oct 21 01:04:33.661397 2022] [wsgi:error] [pid 69391]
>> [Fri Oct 21 01:04:33.661403 2022] [wsgi:error] [pid 69391]
>> [Fri Oct 21 01:04:33.661408 2022] [wsgi:error] [pid 69391] The 
>> dash_core_components package is deprecated. Please replace
>> [Fri Oct 21 01:04:33.661413 2022] [wsgi:error] [pid 69391] `import 
>> dash_core_components as dcc` with `from dash import dcc`
>> [Fri Oct 21 01:04:33.661417 2022] [wsgi:error] [pid 69391]
>> [Fri Oct 21 01:04:34.825419 2022] [core:info] [pid 69391] [client 
>> 10.2.20.25:41124 <http://10.2.20.25:41124/>] AH00128: File does not exist: 
>> /var/www/html/_dash-component-suites/dash/deps/poly...@7.v2_6_2m1666328797.12.1.min.js
>>  , referer: 
>> http://hd1991356yb/~mec/dash101/app.wsgi/ 
>> <http://hd1991356yb/~mec/dash101/app.wsgi/>
>> 
>> I am for now ignoring the deprecation warnings.
>> 
>> I error comes from the app looking for dash's .js files within /var/www/html 
>> (apache's root).  
>> 
>> How can my app.wsgi alter this path?
>> 
>> I tried adding this to my app.wsgi:
>> 
>> os.environ["DASH_URL_BASE_PATHNAME"] = "/home/mec/public_html/dash101/"
> 
> That is a file system path you are giving it, not a URL path the web server 
> understands.
> 
>  Yes. I expect I should have been trying "~mec/dash101" (except dash 
> complains, wanting it to begin and end with a '/').
> 
> 
> 
>> which does effect where the js files are sought, only not correctly, as the 
>> error is now:
>> 
>> [Fri Oct 21 01:48:29.019458 2022] [core:info] [pid 8597] [client 
>> 10.2.20.25:43445 <http://10.2.20.25:43445/>] AH00128: File does not exist: 
>> /var/www/html/home/mec/public_html/dash101/_dash-component-suites

Re: [modwsgi] Random segfaults of quiescent mod_wsgi processes

[Graham Dumpleton]

How much memory do the processes use? Maybe the system OOM process killer is 
killing the processes as they consume lots of memory and the system thinks it 
is running low. There were some potential problems introduced with Python 3.9 
with how process are shutdown and that causes embedded systems to fail on 
shutdown.

See:

https://modwsgi.readthedocs.io/en/master/release-notes/version-4.9.1.html#features-changed
 
<https://modwsgi.readthedocs.io/en/master/release-notes/version-4.9.1.html#features-changed>

You can try setting:

WSGIDestroyInterpreter Off

as mentioned in those change notes and see if it goes away.

Other than that, if you are confident that no new requests are arriving, can 
only suggest you work out if there are background threads running in Python.

You can do that be adding code as described in:

https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#extracting-python-stack-traces
 
<https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html#extracting-python-stack-traces>

and triggering a dump of running threads by touching a file in the file system.

It might also be helpful if you can work out how to have the system preserve 
core dumps from Apache so they can be used to extract a true process stack 
trace as that may give a clue.

Graham

> On 24 Oct 2022, at 3:51 am, stuart mcgraw  wrote:
> 
> Thanks for that suggestion.  I passed it on to the site admin made and he 
> made the "application-group=%{GLOBAL}" change, but unfortunately it made no 
> difference, the segfaults are still occurring as before.  Is there anything 
> else I can look at?  The current configuration is:
> 
> WSGIDaemonProcess jmwsgi processes=2 threads=10 \
> display-name=apache2-jmwsgi locale=en_US.UTF-8 lang=en_US.UTF-8
> WSGIScriptAlias /jmwsgi /usr/local/apache2/jmdictdb/wsgifiles/jmdictdb.wsgi \
> process-group=jmwsgi application-group=%{GLOBAL}
> 
> Would changing to "process=N threads=1" or "processes=1 threads=N" provide 
> any useful info?  Apache, mod_wsgi and the other web server components were 
> all built there (ie, they are not from distro-supplied packages.)  Are the 
> symptoms consistent with a mismatched library or some other build 
> configuration issue?  Or conversely, maybe they make that unlikely? 
> On Friday, October 21, 2022 at 11:48:51 PM UTC-6 Graham Dumpleton wrote:
> Try changing it to:
> 
> WSGIScriptAlias /jmwsgi /usr/local/apache2/jmdictdb/wsgifiles/jmdictdb.wsgi \
>   process-group=jmwsgi application-group=%{GLOBAL}
> 
> You are possibly using a third party Python module which isn't designed to 
> work in Python sub interpreters. That application group value forces the main 
> Python interpreter context to be used, which can avoid problems with crashes, 
> or thread deadlocks when such broken modules are used.
> 
> 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>
> 
> That option on WSGIScriptAlias has same affect as WSGIAplicationGroup but is 
> more specific. For same reason, your use of WSGIProcessGroup is redundant as 
> process group setting on WSGIScriptAlias takes precedence.
> 
> Graham
> 
> 
>> On 22 Oct 2022, at 2:35 pm, stuart mcgraw > > wrote:
>> 
> 
>> My apologies for the delayed response, I thought I had my google email 
>> forwarded to my main email account but... :-(
>> 
>> My intent was that the processes run in daemon mode.  I had missed the info 
>> about the WSGIRestrictEmbedded directive when I went through the doc, I'll 
>> ask the admin there to add that.  The full configuration for wsgi is:
>> 
>>   WSGIDaemonProcess jmwsgi processes=2 threads=10 \
>>   display-name=apache2-jmwsgi locale=en_US.UTF-8 lang=en_US.UTF-8
>>   WSGIProcessGroup jmwsgi
>>   WSGIScriptAlias /jmwsgi 
>> /usr/local/apache2/jmdictdb/wsgifiles/jmdictdb.wsgi \
>>   process-group=jmwsgi
>> # Serve static files directly without using the app.
>>   Alias /jmwsgi/web/ /usr/local/apache2/jmdictdb/
>>   
>>   DirectoryIndex disabled
>>   Require all granted
>>   
>> 
>> The server has a number of virtual hosts and there were a few mod_wsgi 
>> "Loading Python" messages in the error log for one of them (for ssl) but 
>> nothing looking errorish and only a few, nowhere near the number of segfault 
>> messages:
>> 
>>   [Sat Oct 01 07:50:12.090697 2022] [wsgi:info] [pid 731154:tid 
>> 140442461062912] [remote *.*.*.*:40566] mod_wsgi (pid=731154, 
>> process=

Re: [modwsgi] Random segfaults of quiescent mod_wsgi processes

[Graham Dumpleton]

Try changing it to:

WSGIScriptAlias /jmwsgi /usr/local/apache2/jmdictdb/wsgifiles/jmdictdb.wsgi \
  process-group=jmwsgi application-group=%{GLOBAL}

You are possibly using a third party Python module which isn't designed to work 
in Python sub interpreters. That application group value forces the main Python 
interpreter context to be used, which can avoid problems with crashes, or 
thread deadlocks when such broken modules are used.

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>

That option on WSGIScriptAlias has same affect as WSGIAplicationGroup but is 
more specific. For same reason, your use of WSGIProcessGroup is redundant as 
process group setting on WSGIScriptAlias takes precedence.

Graham

> On 22 Oct 2022, at 2:35 pm, stuart mcgraw  wrote:
> 
> My apologies for the delayed response, I thought I had my google email 
> forwarded to my main email account but... :-(
> 
> My intent was that the processes run in daemon mode.  I had missed the info 
> about the WSGIRestrictEmbedded directive when I went through the doc, I'll 
> ask the admin there to add that.  The full configuration for wsgi is:
> 
>   WSGIDaemonProcess jmwsgi processes=2 threads=10 \
>   display-name=apache2-jmwsgi locale=en_US.UTF-8 lang=en_US.UTF-8
>   WSGIProcessGroup jmwsgi
>   WSGIScriptAlias /jmwsgi /usr/local/apache2/jmdictdb/wsgifiles/jmdictdb.wsgi 
> \
>   process-group=jmwsgi
> # Serve static files directly without using the app.
>   Alias /jmwsgi/web/ /usr/local/apache2/jmdictdb/
>   
>   DirectoryIndex disabled
>   Require all granted
>   
> 
> The server has a number of virtual hosts and there were a few mod_wsgi 
> "Loading Python" messages in the error log for one of them (for ssl) but 
> nothing looking errorish and only a few, nowhere near the number of segfault 
> messages:
> 
>   [Sat Oct 01 07:50:12.090697 2022] [wsgi:info] [pid 731154:tid 
> 140442461062912] [remote *.*.*.*:40566] mod_wsgi (pid=731154, 
> process='jmwsgi', application='www.edrdg.org 
> <http://www.edrdg.org/>|/jmwsgi'): Loading Python script file 
> '/usr/local/apache2/jmdictdb/wsgifiles/jmdictdb.wsgi'.
> 
> But the wsgi configuration stuff is outside all the virtutal hosts.
> 
> When the server starts, there are a couple messages in the main error log 
> file like:
> 
>   [Sat Oct 01 06:42:26.499086 2022] [wsgi:info] [pid 731041:tid 
> 140442622753728] mod_wsgi (pid=731041): Starting process 'jmwsgi' with 
> uid=33, gid=33 and threads=10.
>   [Sat Oct 01 06:42:26.499518 2022] [wsgi:info] [pid 731039:tid 
> 140442622753728] mod_wsgi (pid=731039): Starting process 'jmwsgi' with 
> uid=33, gid=33 and threads=10.
> 
> and these are followed/interleaved with the "Initializing Python" and "Attach 
> interpreter" messages but after server startup the messages are limited to 
> the sets of three I showed: "Initializing Python" and "Attach interpreter" 
> followed sometime later by the Segmentation fault.
> 
> Does any of that help?
> On Sunday, October 16, 2022 at 4:16:09 PM UTC-6 Graham Dumpleton wrote:
> What other mod_wsgi configuration is there besides the WSGIDaemonProcess 
> directive? That alone only creates a mod_wsgi daemon process group, but does 
> not tell mod_wsgi to use it. Thus cannot tell whether you are using embedded 
> mode or daemon mode. The logs are also odd in that would expect to see other 
> messages in there around when processes are created if using daemon mode, 
> plus an indication of whether a message is being generated from an Apache 
> child process or mod_wsgi daemon process.
> 
> So can you supply the other parts of the mod_wsgi configuration so can see if 
> properly using daemon mode or not. Also look for logs from mod_wsgi in any 
> per virtual host specific error log file and not just main Apache error log 
> if you separate them. Finally, if you are only intending to use mod_wsgi 
> daemon mode, ensure you add the directive:
> 
> WSGIRestrictEmbedded On
> 
> outside of all VirtualHost definitions so that any attempt to intitialise/use 
> Python in main Apache child processes is disabled.
> 
> Graham
> 
> 
>> On 17 Oct 2022, at 8:07 am, stuart mcgraw > > wrote:
>> 
> 
>> I am author of a Flask application running under Linux/Apache mod_wsgi that 
>> is experiencing intermittent, random segmentation faults.  
>> 
>> What is unusual is that the mod_wsgi process segfaults are occurring not at 
>> startup when mod_wsgi is 

Re: [modwsgi] HOWTO: configure apache with UserDir and WSGI

[Graham Dumpleton]

> On 21 Oct 2022, at 6:40 pm, Malcolm Cook  wrote:
> 
> Hello,
> 
> I have configured apache2 for running any .wsgi apps out of ~/public_html 
> 
> It works for a simple ~/public_html/hello_world.wsgi
> 
> Hooray!
> 
> However, I am having trouble when my app uses
> 
> /usr/bin/python3 -m venv venv
> 
> with the simplest of dash apps.
> 
> I have so far learned to include in my app.wsgi the following:
> 
> site.addsitedir('/home/mec/public_html/dash101/dash101.wsgi')

The site.addsitedir() function accepts a directory, not a file. For working 
with virtual environments ensure you read


https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html

> allowing the app to find the dash modules installed into its venv when run 
> under apache mod_wsgi.
> 
> The app now works from the command line; when run under apache mod_wsgi it 
> only successfully finds the modules in the venv but then fails with:
> 
> [root@hd1991356yb mec]# [Fri Oct 21 01:04:29.974555 2022] [wsgi:info] [pid 
> 69391] mod_wsgi (pid=69391): Create interpreter 
> 'hd1991356yb.sgc.loc|/~mec/dash101/app.wsgi'.
> [Fri Oct 21 01:04:29.989457 2022] [wsgi:info] [pid 69391] [client 
> 10.2.20.25:41124] mod_wsgi (pid=69391, process='', 
> application='hd1991356yb.sgc.loc|/~mec/dash101/app.wsgi'): Loading Python 
> script file '/home/mec/public_html/dash101/app.wsgi'., referer: 
> http://hd1991356yb/~mec/dash101/
> [Fri Oct 21 01:04:30.891229 2022] [wsgi:error] [pid 69391] 
> /home/mec/public_html/dash101/app.py:2: UserWarning:
> [Fri Oct 21 01:04:30.891279 2022] [wsgi:error] [pid 69391] The 
> dash_html_components package is deprecated. Please replace
> [Fri Oct 21 01:04:30.891289 2022] [wsgi:error] [pid 69391] `import 
> dash_html_components as html` with `from dash import html`
> [Fri Oct 21 01:04:30.891298 2022] [wsgi:error] [pid 69391]   import 
> dash_html_components as html
> [Fri Oct 21 01:04:33.661364 2022] [wsgi:error] [pid 69391] 
> /home/mec/public_html/dash101/app.py:4: UserWarning:
> [Fri Oct 21 01:04:33.661397 2022] [wsgi:error] [pid 69391]
> [Fri Oct 21 01:04:33.661403 2022] [wsgi:error] [pid 69391]
> [Fri Oct 21 01:04:33.661408 2022] [wsgi:error] [pid 69391] The 
> dash_core_components package is deprecated. Please replace
> [Fri Oct 21 01:04:33.661413 2022] [wsgi:error] [pid 69391] `import 
> dash_core_components as dcc` with `from dash import dcc`
> [Fri Oct 21 01:04:33.661417 2022] [wsgi:error] [pid 69391]
> [Fri Oct 21 01:04:34.825419 2022] [core:info] [pid 69391] [client 
> 10.2.20.25:41124] AH00128: File does not exist: 
> /var/www/html/_dash-component-suites/dash/deps/polyfill@7.v2_6_2m1666328797.12.1.min.js,
>  referer: http://hd1991356yb/~mec/dash101/app.wsgi/
> 
> I am for now ignoring the deprecation warnings.
> 
> I error comes from the app looking for dash's .js files within /var/www/html 
> (apache's root).  
> 
> How can my app.wsgi alter this path?
> 
> I tried adding this to my app.wsgi:
> 
> os.environ["DASH_URL_BASE_PATHNAME"] = "/home/mec/public_html/dash101/"

That is a file system path you are giving it, not a URL path the web server 
understands.

> which does effect where the js files are sought, only not correctly, as the 
> error is now:
> 
> [Fri Oct 21 01:48:29.019458 2022] [core:info] [pid 8597] [client 
> 10.2.20.25:43445] AH00128: File does not exist: 
> /var/www/html/home/mec/public_html/dash101/_dash-component-suites/dash/deps/polyfill@7.v2_6_2m1666328797.12.1.min.js,
>  referer: http://hd1991356yb/~mec/dash101/app.wsgi

Where is the "_dash-component-suites" actually located on the file system. That 
directory should be copied into /var/www/html and DASH_URL_BASE_PATHNAME not 
set, or, you need to set up the Apache Alias directory to map some URL prefix 
to filesystem location where it is.

> So far, apache2 is configured with:
> 
> LoadModule wsgi_module 
> /usr/lib64/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so
> 
> 
> UserDir public_html
> 
> 
> 
> AllowOverride FileInfo AuthConfig Limit Indexes
> Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec ExecCGI
> Require method GET POST OPTIONS
> AddHandler cgi-script .cgi
> AddHandler wsgi-script .wsgi
> 
> 
> I am not issuing any other wSGI configuration directives in my apache2 
> configuration.
> 
> Perhaps I should not expect apache2+userdir+mod_wsgi to work at all...???

In general it is best to avoid using mod_userdir with mod_wsgi as it confuses 
typical WSGI application URL handling.

Why are you trying to use mod_userdir. Do you not control the whole Apache 
server?

> All advice as to how to proceed very welcome.
> 
> update:  I've now read 
> https://groups.google.com/g/modwsgi/c/Lnik3YHFujA/m/3QRuwEZXP6sJ and have 
> tried the approach mentioned there:
> 
> WSGIRestrictEmbedded On
> 
> WSGIDaemonProcess mec
> 
> WSGIProcessGroup mec user=mec
> 
> 
> I modifed it remove the (now deprecated?) `user=mec` (which causes apache 
> rest

Re: [modwsgi] Random segfaults of quiescent mod_wsgi processes

[Graham Dumpleton]

What other mod_wsgi configuration is there besides the WSGIDaemonProcess 
directive? That alone only creates a mod_wsgi daemon process group, but does 
not tell mod_wsgi to use it. Thus cannot tell whether you are using embedded 
mode or daemon mode. The logs are also odd in that would expect to see other 
messages in there around when processes are created if using daemon mode, plus 
an indication of whether a message is being generated from an Apache child 
process or mod_wsgi daemon process.

So can you supply the other parts of the mod_wsgi configuration so can see if 
properly using daemon mode or not. Also look for logs from mod_wsgi in any per 
virtual host specific error log file and not just main Apache error log if you 
separate them. Finally, if you are only intending to use mod_wsgi daemon mode, 
ensure you add the directive:

WSGIRestrictEmbedded On

outside of all VirtualHost definitions so that any attempt to intitialise/use 
Python in main Apache child processes is disabled.

Graham

> On 17 Oct 2022, at 8:07 am, stuart mcgraw  wrote:
> 
> I am author of a Flask application running under Linux/Apache mod_wsgi that 
> is experiencing intermittent, random segmentation faults.  
> 
> What is unusual is that the mod_wsgi process segfaults are occurring not at 
> startup when mod_wsgi is loaded, or at when an incoming request accesses the 
> app, but when the wsgi processes are just sitting there, quiescent.
> 
> From a user's point of view, everything looks fine, the mod_wsgi processes 
> and the app respond with the right results with no sign of trouble at the 
> client's browser.  But looking at the Apache logs shows the wsgi processes 
> periodically segfaulting and getting restarted with no correlated incoming 
> requests.  They die sometimes after running for a few minutes, sometimes 
> after a few hours.  There are no incoming requests to the the wsgi app logged 
> near the time of these crashes.
> 
> For example:
> [Mon May 30 22:35:43.040387 2022] [wsgi:info] [pid 2575903:tid 
> 139929303559104] mod_wsgi (pid=2575903): Initializing Python.
> [Mon May 30 22:35:43.099053 2022] [wsgi:info] [pid 2575903:tid 
> 139929303559104] mod_wsgi (pid=2575903): Attach interpreter ''.
> [Tue May 31 01:29:06.434000 2022] [core:notice] [pid 2876203:tid 
> 139929303559104] AH00052: child pid 2511562 exit signal Segmentation fault 
> (11)
> [Tue May 31 01:29:07.466268 2022] [wsgi:info] [pid 2605661:tid 
> 139929303559104] mod_wsgi (pid=2605661): Initializing Python.
> [Tue May 31 01:29:07.517413 2022] [wsgi:info] [pid 2605661:tid 
> 139929303559104] mod_wsgi (pid=2605661): Attach interpreter ''.
> [Tue May 31 04:14:59.405491 2022] [core:notice] [pid 2876203:tid 
> 139929303559104] AH00052: child pid 2575903 exit signal Segmentation fault 
> (11)
> 
> My wsgi app is still being tested so other than infrequent requests generated 
> by me and a few other people there is very little traffic to it.  However the 
> web server itself is handling some continuous moderate volume of traffic to 
> other apps including to C, Python and PHP CGI apps.
> 
> What I know about the environment (if any other info would be useful I'll try 
> and dig it up):
> 
> $ cat /etc/*release
> PRETTY_NAME="Debian GNU/Linux 11 (bullseye)
> 
> Apache, mod_wsgi, python were all built from source by the site's 
> administrator.
> 
> There are (at least) two Python's on the system:
>  /usr/bin/python3 -- 3.9.2
>  /usr/local/bin/python3 -- 3.10.1
> 
> Apachche/mod_wsgi is was supposedly built against python-3.10.  From 
> the http server header:
>   Apache/2.4.54 (Unix) OpenSSL/1.1.1n mod_wsgi/4.9.4 Python/3.10 PHP/7.4.23
> 
> The Apache .conf file uses:
>   WSGIDaemonProcess myapp processes=2 threads=10 \
> display-name=apache2-myapp locale=en_US.UTF-8 lang=en_US.UTF-8
> 
> $ /usr/local/apache2/bin/httpd -V
> Server version: Apache/2.4.54 (Unix)
> Server built:   Oct 13 2022 00:07:38
> Server's Module Magic Number: 20120211:124
> Server loaded:  APR 1.6.5, APR-UTIL 1.6.1, PCRE 10.36 2020-12-04
> Compiled using: APR 1.6.5, APR-UTIL 1.6.1, PCRE 10.36 2020-12-04
> Architecture:   64-bit
> Server MPM: event
>   threaded: yes (fixed thread count)
> forked: yes (variable process count)
> Server compiled with
>  -D APR_HAS_SENDFILE
>  -D APR_HAS_MMAP
>  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>  -D APR_USE_SYSVSEM_SERIALIZE
>  -D APR_USE_PTHREAD_SERIALIZE
>  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
>  -D APR_HAS_OTHER_CHILD
>  -D AP_HAVE_RELIABLE_PIPED_LOGS
>  -D DYNAMIC_MODULE_LIMIT=256
>  -D HTTPD_ROOT="/usr/local/apache2"
>  -D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
>  -D DEFAULT_PIDLOG="logs/httpd.pid"
>  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
>  -D DEFAULT_ERRORLOG="logs/error_log"
>  -D AP_TYPES_CONFIG_FILE="conf/mime.types"
>  -D SERVER_CONFIG_FILE="conf/httpd.conf"
> 
> $ bin/httpd -M
> Loaded Modules:
>  core_module (static)
>  so_module (static)
>  http_module (static)
>  mpm_event_module 

Re: [modwsgi] SSLError("Can't connect to HTTPS URL because the SSL module is not available.")

[Graham Dumpleton]

No, can't help with that. Apache on Windows is already a huge pain and in 
general would never recommend using Apache on Windows if can avoid it.

> On 14 Oct 2022, at 11:53 am, Ryan McClellan  wrote:
> 
> Wow thanks for that information.  There is another webapp using apache to 
> handle requests so I think mod_ssl has to stay.
> 
> Do you know a way  to recompile apache ssl module to match python's? For 
> windows? I see lots of linux solutions for this.
>  
> 
> 
> 
> 
> On Thursday, October 13, 2022 at 7:47:27 PM UTC-4 Graham Dumpleton wrote:
> The problem is likely going to be that Apache SSL module is compiled against 
> a different SSL library version than Python and so when the Python extension 
> verifies things it sees a mismatch and fails.
> 
> If you don't need to handler HTTPS requests in Apache, then ensure that 
> mod_ssl is not being loaded and try again.
> 
> 
>> On 14 Oct 2022, at 10:44 am, Ryan McClellan > > wrote:
>> 
> 
>> Thanks for your response,
>> 
>> No, issue is not resolved. I closed the issue on github after reading you 
>> direct people here for environment/setup issues.
>> I didn't encounter this issue when using a fresh apache install. 
>> I'm integrating my code base into an existing system using 32bit Apache 
>> (2.4.34). Sadly, upgrading isn't an option right now. I had to install 32bit 
>> python to get mod_wsgi to play nice with apache.
>> Current stack looks like: Apache/2.4.34 (Win32) OpenSSL/1.1.0h PHP/7.2.8 
>> mod_wsgi/4.9.4 Python/3.9
>> 
>> Error says SSL Module not available: But using my py venv I can see ssl 
>> exists. pyopenssl is also installed:
>> 
>> C:\>wearable\env\Scripts\python.exe
>> Python 3.9.10 (tags/v3.9.10:f2f3f53, Jan 17 2022, 15:01:48) [MSC v.1929 32 
>> bit (Intel)] on win32
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import ssl
>> >>> print(ssl)
>> 
>> >>>
>> 
>> Let me know if you have any ideas where this could be going wrong.
>> 
>> On Thursday, October 13, 2022 at 6:40:40 PM UTC-4 Graham Dumpleton wrote:
>> Am assuming this has been resolved since you closed the issue you created.
>> 
>> https://github.com/GrahamDumpleton/mod_wsgi/issues/800 
>> <https://github.com/GrahamDumpleton/mod_wsgi/issues/800>
>> 
>> Yes/No?
>> 
>> Be aware that using Anaconda Python with mod_wsgi causes all sorts of 
>> problems with SSL library usage.
>> 
>> 
>>> On 14 Oct 2022, at 5:57 am, Ryan McClellan > wrote:
>>> 
>> 
>>> I have flask web app running on Apache using mod_wsgi. Web app is on a 
>>> virtualhost using this config:
>>> 
>>> LoadFile "C:\Program Files (x86)\Python39-32\python39.dll" 
>>> LoadModule wsgi_module 
>>> "C:/wearable/env/Lib/site-packages/mod_wsgi/server/mod_wsgi.cp39-win32.pyd" 
>>> WSGIPythonHome "C:/wearable/env" 
>>> WSGIApplicationGroup %{GLOBAL} 
>>> Listen 0.0.0.0:443 <http://0.0.0.0:443/> 
>>>  
>>> SSLEngine on 
>>> SSLCertificateFile "${SRVROOT}/conf/new_cert/ServerCertificate.crt" 
>>> SSLCertificateKeyFile "${SRVROOT}/conf/new_cert/my_cert.key" 
>>> SSLCertificateChainFile "${SRVROOT}/conf/new_cert/ChainBundle1.crt" 
>>>  
>>> Require all granted 
>>>  
>>> WSGIScriptAlias / C:/wearable/start.wsgi 
>>> 
>>> 
>>> mod_wsgi/Apache is serving the web app on 443. Certificate looks good.
>>> The problem occurs when using a function that make HTTPS call to another 
>>> server. I get SSL error.
>>> I'm able to manually run those same functions from the python virtual 
>>> environment and everything works perfect. Seems like mod_wsgi isn't able to 
>>> access SSL module.
>>> 
>>> Any ideas on how I can alleviate this issue? Thanks, Ryan
>>> 
>>> See following stack trace:
>>> 
>>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>>> 10.252.57.4:53547 <http://10.252.57.4:53547/>] Traceback (most recent call 
>>> last):\r, 
>>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>>> 10.252.57.4:53547 <http://10.252.57.4:53547/>] File 
>>> "C:\\wearable\\__init__.py", line 92, in \r, 
>>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>>> 10.252

Re: [modwsgi] SSLError("Can't connect to HTTPS URL because the SSL module is not available.")

[Graham Dumpleton]

The problem is likely going to be that Apache SSL module is compiled against a 
different SSL library version than Python and so when the Python extension 
verifies things it sees a mismatch and fails.

If you don't need to handler HTTPS requests in Apache, then ensure that mod_ssl 
is not being loaded and try again.

> On 14 Oct 2022, at 10:44 am, Ryan McClellan  wrote:
> 
> Thanks for your response,
> 
> No, issue is not resolved. I closed the issue on github after reading you 
> direct people here for environment/setup issues.
> I didn't encounter this issue when using a fresh apache install. 
> I'm integrating my code base into an existing system using 32bit Apache 
> (2.4.34). Sadly, upgrading isn't an option right now. I had to install 32bit 
> python to get mod_wsgi to play nice with apache.
> Current stack looks like: Apache/2.4.34 (Win32) OpenSSL/1.1.0h PHP/7.2.8 
> mod_wsgi/4.9.4 Python/3.9
> 
> Error says SSL Module not available: But using my py venv I can see ssl 
> exists. pyopenssl is also installed:
> 
> C:\>wearable\env\Scripts\python.exe
> Python 3.9.10 (tags/v3.9.10:f2f3f53, Jan 17 2022, 15:01:48) [MSC v.1929 32 
> bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import ssl
> >>> print(ssl)
> 
> >>>
> 
> Let me know if you have any ideas where this could be going wrong.
> 
> On Thursday, October 13, 2022 at 6:40:40 PM UTC-4 Graham Dumpleton wrote:
> Am assuming this has been resolved since you closed the issue you created.
> 
> https://github.com/GrahamDumpleton/mod_wsgi/issues/800 
> <https://github.com/GrahamDumpleton/mod_wsgi/issues/800>
> 
> Yes/No?
> 
> Be aware that using Anaconda Python with mod_wsgi causes all sorts of 
> problems with SSL library usage.
> 
> 
>> On 14 Oct 2022, at 5:57 am, Ryan McClellan > > wrote:
>> 
> 
>> I have flask web app running on Apache using mod_wsgi. Web app is on a 
>> virtualhost using this config:
>> 
>> LoadFile "C:\Program Files (x86)\Python39-32\python39.dll" 
>> LoadModule wsgi_module 
>> "C:/wearable/env/Lib/site-packages/mod_wsgi/server/mod_wsgi.cp39-win32.pyd" 
>> WSGIPythonHome "C:/wearable/env" 
>> WSGIApplicationGroup %{GLOBAL} 
>> Listen 0.0.0.0:443 <http://0.0.0.0:443/> 
>>  
>> SSLEngine on 
>> SSLCertificateFile "${SRVROOT}/conf/new_cert/ServerCertificate.crt" 
>> SSLCertificateKeyFile "${SRVROOT}/conf/new_cert/my_cert.key" 
>> SSLCertificateChainFile "${SRVROOT}/conf/new_cert/ChainBundle1.crt" 
>>  
>> Require all granted 
>>  
>> WSGIScriptAlias / C:/wearable/start.wsgi 
>> 
>> 
>> mod_wsgi/Apache is serving the web app on 443. Certificate looks good.
>> The problem occurs when using a function that make HTTPS call to another 
>> server. I get SSL error.
>> I'm able to manually run those same functions from the python virtual 
>> environment and everything works perfect. Seems like mod_wsgi isn't able to 
>> access SSL module.
>> 
>> Any ideas on how I can alleviate this issue? Thanks, Ryan
>> 
>> See following stack trace:
>> 
>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>> 10.252.57.4:53547 <http://10.252.57.4:53547/>] Traceback (most recent call 
>> last):\r, 
>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>> 10.252.57.4:53547 <http://10.252.57.4:53547/>] File 
>> "C:\\wearable\\__init__.py", line 92, in \r, 
>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>> 10.252.57.4:53547 <http://10.252.57.4:53547/>] cc = 
>> CariumConnector(test_mode=read_bool(conf['TEST_MODE']), logger=logger, 
>> rbe=rbe, db=db)\r, 
>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>> 10.252.57.4:53547 <http://10.252.57.4:53547/>] File 
>> "C:\\wearable\\CariumConnector.py", line 58, in __init__\r, 
>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>> 10.252.57.4:53547 <http://10.252.57.4:53547/>] self.kwargs = 
>> self.__login()\r,
>>  [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>> 10.252.57.4:53547 <http://10.252.57.4:53547/>] File 
>> "C:\\wearable\\CariumConnector.py", line 386, in __login\r, 
>> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
>> 10.252.57.4:53547 <http://10.252.57.4:5354

Re: [modwsgi] SSLError("Can't connect to HTTPS URL because the SSL module is not available.")

[Graham Dumpleton]

Am assuming this has been resolved since you closed the issue you created.

https://github.com/GrahamDumpleton/mod_wsgi/issues/800 


Yes/No?

Be aware that using Anaconda Python with mod_wsgi causes all sorts of problems 
with SSL library usage.

> On 14 Oct 2022, at 5:57 am, Ryan McClellan  wrote:
> 
> I have flask web app running on Apache using mod_wsgi. Web app is on a 
> virtualhost using this config:
> 
> LoadFile "C:\Program Files (x86)\Python39-32\python39.dll" 
> LoadModule wsgi_module 
> "C:/wearable/env/Lib/site-packages/mod_wsgi/server/mod_wsgi.cp39-win32.pyd" 
> WSGIPythonHome "C:/wearable/env" 
> WSGIApplicationGroup %{GLOBAL} 
> Listen 0.0.0.0:443 
>  
> SSLEngine on 
> SSLCertificateFile "${SRVROOT}/conf/new_cert/ServerCertificate.crt" 
> SSLCertificateKeyFile "${SRVROOT}/conf/new_cert/my_cert.key" 
> SSLCertificateChainFile "${SRVROOT}/conf/new_cert/ChainBundle1.crt" 
>  
> Require all granted 
>  
> WSGIScriptAlias / C:/wearable/start.wsgi 
> 
> 
> mod_wsgi/Apache is serving the web app on 443. Certificate looks good.
> The problem occurs when using a function that make HTTPS call to another 
> server. I get SSL error.
> I'm able to manually run those same functions from the python virtual 
> environment and everything works perfect. Seems like mod_wsgi isn't able to 
> access SSL module.
> 
> Any ideas on how I can alleviate this issue? Thanks, Ryan
> 
> See following stack trace:
> 
> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] Traceback (most recent call last):\r, 
> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547]   File "C:\\wearable\\__init__.py", line 92, in 
> \r, 
> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] cc = 
> CariumConnector(test_mode=read_bool(conf['TEST_MODE']), logger=logger, 
> rbe=rbe, db=db)\r, 
> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547]   File "C:\\wearable\\CariumConnector.py", line 58, in 
> __init__\r, 
> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] self.kwargs = self.__login()\r,
>  [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] File "C:\\wearable\\CariumConnector.py", line 386, in 
> __login\r, 
> [Wed Oct 12 22:32:45.522680 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] result = 
> requests.post(f"{self.API_HOST}/identity/v1/login/", data={'username': 
> self.__carium_user,'password': self.__carium_pass})\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547]   File 
> "C:\\wearable\\env\\Lib\\site-packages\\requests\\api.py", line 115, in 
> post\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] return request("post", url, data=data, json=json, 
> **kwargs)\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547]   File 
> "C:\\wearable\\env\\Lib\\site-packages\\requests\\api.py", line 59, in 
> request\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] return session.request(method=method, url=url, 
> **kwargs)\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547]   File 
> "C:\\wearable\\env\\Lib\\site-packages\\requests\\sessions.py", line 587, in 
> request\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] resp = self.send(prep, **send_kwargs)\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547]   File 
> "C:\\wearable\\env\\Lib\\site-packages\\requests\\sessions.py", line 701, in 
> send\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] r = adapter.send(request, **kwargs)\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547]   File 
> "C:\\wearable\\env\\Lib\\site-packages\\requests\\adapters.py", line 563, in 
> send\r, 
> [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] raise SSLError(e, request=request)\r,
>  [Wed Oct 12 22:32:45.523679 2022] [wsgi:error] [pid 58060:tid 1952] [client 
> 10.252.57.4:53547] requests.exceptions.SSLError: 
> HTTPSConnectionPool(host='api.carium.com', port=443): Max retries exceeded 
> with url: /identity/v1/login/ (Caused by SSLError("Can't connect to HTTPS URL 
> because the SSL module is not available."))\r,
> 
> -- 
> 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 t

Re: [modwsgi] Forbidden You don't have permission to access / on this server.

[Graham Dumpleton]

Don't put your files under the root user home directory. The permissions on 
/root don't allow other users to look into the directory, meaning the Apache 
user that the Apache processes run as cannot look into that directory.

Note that the permissions on /root should NOT be changed. Put your project 
files somewhere else.

Graham

> On 29 Sep 2022, at 6:45 pm, Shiva Kumar  wrote:
> 
> 
> I have flask application that is runnig on apache(httpd) using mod_wsgi I 
> have a python environment set up. Using WSGIDaemonProcess with properly set 
> python-home I was able to run a basic "Flask test" app to verify things 
> working properly. but when I using WSGIDaemonProcess to deploy I'm getting 
> error.
> 
> 3180 [Thu Sep 29 13:47:07.042380 2022] [core:error] [pid 15230] 
> (13)Permission denied: [client 172.70.90.229:14996] AH00035: access to / 
> denied (filesystem path '/root/nse') because search permissions are 
> missing on a component of the path
>3181 172.70.90.229 - - [29/Sep/2022:13:47:07 +0530] "GET / HTTP/1.1" 403 
> 202 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0"
>3182 [Thu Sep 29 13:47:07.050614 2022] [core:error] [pid 15227] 
> (13)Permission denied: [client 172.70.188.77:37914] AH00035: access to / 
> denied (filesystem path '/root/nse') because search permissions are 
> missing on a component of the path
>3183 172.70.188.77 - - [29/Sep/2022:13:47:07 +0530] "GET / HTTP/1.1" 403 
> 202 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0"
>3184 [Thu Sep 29 13:47:07.212233 2022] [core:error] [pid 15229] 
> (13)Permission denied: [client 172.70.85.81:23788] AH00035: access to / 
> denied (filesystem path '/root/nse') because search permissions are 
> missing on a component of the path
>3185 172.70.85.81 - - [29/Sep/2022:13:47:07 +0530] "GET / HTTP/1.1" 403 
> 202 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0"
>3186 [Thu Sep 29 13:47:07.583472 2022] [core:error] [pid 15228] 
> (13)Permission denied: [client 172.71.178.103:52888] AH00035: access to / 
> denied (filesystem path '/root/nse') because search permissions are 
> missing on a component of the path
>3187 172.71.178.103 - - [29/Sep/2022:13:47:07 +0530] "GET / HTTP/1.1" 403 
> 202 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0"
> 
> and this the passenger_wsgi.py file code
> 
> # from app import app as application
> 
> #from nse_stock_master.ReadData import app as application
> 
> 
> # importing the sys module
> import sys
> 
> # appending the directory of ReadData.py
> # in the sys.path list
> sys.path.insert(0,'/var/www/html/tickerscreener')
> 
> activate_this 
> ='/root/.local/share/virtualenvs/tickerscreener-VNoT57Rh/bin/activate_this.py'
> with open(activate_this) as file_:
> exect(file_.read(), dict(__file__=activate_this))
> 
> from app import app as application
> 
> 
> # now we can import app
> #from app import app as application
> 
> virtual httpd config 
> 
> VirtualHost *:80>
> 
> ServerName www.tickerscreener.in
> 
>  WSGIDaemonProcess flaskapp user=nse group=nse processes=2 threads=15
>  WSGIScriptAlias / /root/nse/var/www/html/tickerscreener/passenger_wsgi.py
> 
> ServerAlias tickerscreener.in
> 
> 
>  WSGIProcessGroup flaskapp
>  WSGIApplicationGroup %{GLOBAL}
>  Order deny,allow
>  Allow from all
> 
> 
> 
> DocumentRoot /var/www/html/tickerscreener
> 
> ErrorLog /var/www/html/tickerscreener/logs/access.log
> CustomLog /var/www/html/tickerscreener/logs/access.log combined
> 
> 
> 
> May I know where I done the mistake 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/aa0f4c63-2558-4011-ae3c-8e9897c95c29n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/994CA139-FCF8-47A1-8880-DE50B4948796%40gmail.com.

Re: [modwsgi] ImportError caused by wrong library path in flask app using WSGI daemon

[Graham Dumpleton]

If your system had "pldd" command, as root user, run it and supply the process 
ID of the Apache parent process (the one running as root). Check that no PHP 
module is loaded and see if the problem library is also preloaded still.

> On 14 Sep 2022, at 1:24 am, Nathan Wendt  wrote:
> 
> Thanks. Taking the php module out still produced the same error. Perhaps 
> there is still a module that requires those system libraries that I am not 
> thinking of? In terms of  mod_wsgi-express, I am not sure how to use that in 
> the setup that I have. Running it on my local machine and accessing it with 
> localhost makes sense. However, my application is running on an external 
> server with its own apache/security configurations. I was not successful 
> trying to access the express server instance. I also ended up trying to set 
> LD_LIBRARY_PATH and then start apache again as well as directly loading the 
> libraries in the config files to no avail. I've seen some of your suggestions 
> to set LD_RUN_PATH and build libraries from source. Unfortunately, I think I 
> would have to build several packages in order for that to work. The reason 
> for using conda was to easily get a newer version of python than the RHEL 
> system comes packaged with. As long as I did not miss a step in any of your 
> suggestions, perhaps there is not a good way to get this to work.
> 
> On Monday, September 5, 2022 at 4:47:29 PM UTC-5 Graham Dumpleton wrote:
> Conda distributions of Python don't play nicely with embedded systems because 
> they ship their own versions of common libraries which are also shipped with 
> the operating system, but where the Conda version can be an incompatible 
> version.
> 
> This causes problems when Python is being embedded in an application (Apache 
> in this case), where the application (Apache) is already linking in the 
> system version of the library.
> 
> Because the dynamic linker only looks at the shared library name, it will see 
> that libz.so is already linked into the application process and use whatever 
> that is, which will then not be the version your Python extension expects and 
> will fail.
> 
> For Apache usually the problem is that you also have mod_php loaded into 
> Apache and it is preloading a lot of PHP extensions which have references to 
> some library which drags in the conflicting system library. This is a known 
> issue with some graphics libraries such as libpng.so pulled in by PHP.
> 
> So the only real way around this in this case is not to load PHP into Apache 
> if you don't need PHP to be enabled. Do that and it may then work.
> 
> If you must have PHP loaded into your primary Apache, then use 
> mod_wsgi-express for your Python application instead and configure the front 
> end Apache where PHP runs to proxy requests through to the mod_wsgi-express 
> instance as necessary.
> 
> So try the following two things.
> 
> 1. Try and run your application using mod_wsgi-express instead of your 
> primary Apache instance and see if that works.
> 2. Disable PHP in your primary Apache instance, completely stop Apache and 
> start it again (not just a reload), and see if it then works.
> 
> Graham
> 
> 
>> On 6 Sep 2022, at 3:31 am, Nathan Wendt > > wrote:
>> 
> 
>> I have a flask application that is run on apache using mod_wsgi. I have a 
>> python environment that I set up using miniconda. Initially, mod_wsgi was 
>> installed using conda. Using a mod_wsgi daemon process with a properly set 
>> python-home, I was able to run a very basic "hello, world" app to verify 
>> things were working properly. I then began to add pieces to the app to 
>> process data and output images. I began to see ImportError in the apache 
>> logs when trying to run the app. The specific error was:
>> 
>> ImportError: /lib64/libz.so.1: version `ZLIB_1.2.9` not found (required by 
>> ~/miniconda3/envs/.../libpng16.so.16)
>> 
>> This error is triggered by importing the rasterio package (which depends on 
>> GDAL, which needs libpng). When I look at the libpng referred to by the 
>> error with ldd, however, it is properly linked to the libz that is in the 
>> conda environment. Somehow the library path only includes the system paths 
>> within the daemon process. If I am to use my conda environment python on the 
>> command line to import rasterio, no such error occurs. It only occurs within 
>> the flask app. I next built mod_wsgi from source using the conda environment 
>> python just to be sure I was having that all linked correctly. The same 
>> error still occurred in the app. When checking the sys.path from within the 
>> app, that all looks appropriate

Re: [modwsgi] Apache server goes down multiple times a week

[Graham Dumpleton]

Yeah, that is what people often do. I didn't want to dictate where you stored 
the config as people do things different.

> On 13 Sep 2022, at 4:56 am, Juan Khawly  wrote:
> 
> Graham,
> 
> Thanks for the deep explanation. This was really helpful to understand better 
> the architecture. 
> 
> In my case, my PROD and DEV applications are in separate machines. I don't 
> think I have to create multiple daemon processes. 
> 
> This is what I settled down:
> 
> 1) Use /etc/environment file to setup my environment variables. There are 
> other processes living in the server that will need to use this file, not 
> only the DJANGO APP. I dont like the idea to create a separate wsgi_dev, 
> wsgi_prod and duplicate the vars. 
> 2) Modify the wsgi.py to:
>   a) Call application = get_wsgi_application() only one time.
>   b) Created a small routine that opens the previous file and reads the VARS 
> to store them ONE TIME at os.environ['VAR1'], os.environ['VAR2']
>   c) Remove VARS from the virtual host since I wont be able to pass them to 
> the DJANGO App.
> 
> I will report back if something goes wrong, but thanks for your time and help
> 
> Juan Khawly
> 
> 
> 
> 
> 
> 
> 
> 
> On Saturday, September 10, 2022 at 12:25:15 PM UTC-4 Juan Khawly wrote:
> Graham,
> 
> If I take the the  get_wsgi_application() out of the function, my site throws 
> error an internal error. Looking inside the logs, it all comes down that my 
> app is not receiving the value of VAR1 or VAR2 that are further used in my 
> settings.py to setup the environment. VAR1 and VAR2 are environment variables 
> that help me recognize if I am in LOCAL, DEV or PROD.
> 
> Also, I honestly didn't understand this comment if you can help me see more 
> clearly. "Be aware that what you are doing is not technically safe because 
> environment variables are global and so if different URLs ended up in 
> different values for the variables, then a different request could change it 
> before you got to use it." 
> 
> My goal is having environmental variables inside my virtual host and pass 
> them to the Django app. I tried this using the environment variables files 
> that Linux uses but I was never successful to pass them to my Django app.
> 
> Thanks,
> Juan Khawly
> 
>  
> 
> 
> On Friday, September 9, 2022 at 9:57:06 PM UTC-4 Graham Dumpleton wrote:
> Be aware that what you are doing is not technically safe because environment 
> variables are global and so if different URLs ended up in different values 
> for the variables, then a different request could change it before you got to 
> use it.
> 
> That said, use:
> 
> import os
> from django.core.wsgi import get_wsgi_application
> os.environ.setdefault('DJANGO_SETTINGS_MODULE', ' project  .settings')
> 
> _application = get_wsgi_application()
> 
> def application(environ, start_response):
> os.environ['VAR1'] = environ.get('VAR1', '')
> os.environ['VAR2'] = environ.get('VAR2', '')
> return _application(environ, start_response)
> 
> In other words, just call get_wsgi_application() once outside of the function.
> 
> Graham
> 
> 
>> On 10 Sep 2022, at 11:36 am, Juan Khawly > wrote:
>> 
> 
>> Graham, 
>> 
>> It does click now. Couple of months ago, I had to modify the original 
>> wsgi.py file to include Environmental variables read from my Virtual Host.
>> 
>> __
>> I changed from: 
>> 
>> On wsgi.py
>> 
>> import os
>> from django.core.wsgi import get_wsgi_application
>> os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project.settings')
>> application = get_wsgi_application()
>> 
>> to
>> 
>> On Virtual Host
>> 
>> SetEnv VAR1 
>> SetEnv VAR2 
>> 
>> On wsgi.py
>> 
>> import os
>> from django.core.wsgi import get_wsgi_application
>> os.environ.setdefault('DJANGO_SETTINGS_MODULE', ' project  .settings')
>> 
>> def application(environ, start_response):
>> os.environ['VAR1'] = environ.get('VAR1', '')
>> os.environ['VAR2'] = environ.get('VAR2', '')
>> _application = get_wsgi_application()
>> return _application(environ, start_response)
>> __
>> 
>> I think I found this solution on a forum and it worked and never expected 
>> that i

Re: [modwsgi] Apache server goes down multiple times a week

[Graham Dumpleton]

> On 11 Sep 2022, at 2:25 am, Juan Khawly  wrote:
> 
> Graham,
> 
> If I take the the  get_wsgi_application() out of the function, my site throws 
> error an internal error. Looking inside the logs, it all comes down that my 
> app is not receiving the value of VAR1 or VAR2 that are further used in my 
> settings.py to setup the environment. VAR1 and VAR2 are environment variables 
> that help me recognize if I am in LOCAL, DEV or PROD.
> 
> Also, I honestly didn't understand this comment if you can help me see more 
> clearly. "Be aware that what you are doing is not technically safe because 
> environment variables are global and so if different URLs ended up in 
> different values for the variables, then a different request could change it 
> before you got to use it." 

SetEnv is not technically for setting environment variables. How they are used 
is dependent on the specific Apache request handler. For CGI scripts they do 
translate to process environment variables since each CGI request is handled in 
a separate process invocation. For PHP, mod_wsgi, mod_perl etc, anything set 
using SetEnv is specific to the request variables and using them to set 
environment variables is not recommended since different contexts in the Apache 
configuration could use SetEnv to pass different values for the same variable 
name. The consequence of this if a request comes in which has one value for the 
variable and sets a process wide environment variable but before it gets to use 
that environment variable another parallel request came in which also overrides 
the environment variable, but with a different value based on what SetEnv 
dictates, then the first request may end up seeing a different value to what 
you would expect to see. In other words, in a multi threaded system you will 
have race conditions because there is no mutex locking on the usage of process 
wide environment variables.

The recommended way of doing things is for different environment types have a 
different WSGI script file as entry point. That WSGI script can then set once 
any process environment variables before importing the real wsgi.py module for 
the project. Do note this still only works where different instances of your 
application are delegated to run in different mod_wsgi daemon process groups. 
You cannot do this if using embedded mode, or where you have only a single 
mod_wsgi daemon process group with multiple instances of your web application.

WSGIDaemonProcess my_project_production 
python-path=/data/home/user/project python-home=/data/home/user/environment/venv
WSGIScriptAlias /prod 
/data/home/user/project/my_project/wsgi_production.py 
process-group=my_project_production application-group=%{GLOBAL}

WSGIDaemonProcess my_project_development 
python-path=/data/home/user/project python-home=/data/home/user/environment/venv
WSGIScriptAlias /dev 
/data/home/user/project/my_project/wsgi_development.py 
process-group=my_project_development application-group=%{GLOBAL}

Since multiple mod_wsgi daemon process groups are going to be required, an 
alternative way is to base decisions off the name of the mod_wsgi daemon 
process group. A wsgi.py file could thus do:

import mod_wsgi

if mod_wsgi.process_group() == "my_project_production":
...
elif mod_wsgi.process_group() == "my_project_development":
...

The important thing is use different daemon process groups for different 
instances of the application using different global configuration, use of 
Python sub interpreters for separation is not enough.

> My goal is having environmental variables inside my virtual host and pass 
> them to the Django app. I tried this using the environment variables files 
> that Linux uses but I was never successful to pass them to my Django app.

If you mean environment variables set in your user login shell environment then 
no it will not as Apache runs as a completely different user. If you want to 
override environment variables for Apache, they would need to be set in the 
systemd/Apache startup scripts.

> 
> Thanks,
> Juan Khawly
> 
>  
> 
> 
> On Friday, September 9, 2022 at 9:57:06 PM UTC-4 Graham Dumpleton wrote:
> Be aware that what you are doing is not technically safe because environment 
> variables are global and so if different URLs ended up in different values 
> for the variables, then a different request could change it before you got to 
> use it.
> 
> That said, use:
> 
> import os
> from django.core.wsgi import get_wsgi_application
> os.environ.setdefault('DJANGO_SETTINGS_MODULE', ' project  .settings')
> 
> _application = get_wsgi_application()
> 
> def application(environ, start_response):
> os.environ['VAR1'] = environ.get('VAR1', '')
> os.envir

Re: [modwsgi] Apache server goes down multiple times a week

[Graham Dumpleton]

Be aware that what you are doing is not technically safe because environment 
variables are global and so if different URLs ended up in different values for 
the variables, then a different request could change it before you got to use 
it.

That said, use:

import os
from django.core.wsgi import get_wsgi_application
os.environ.setdefault('DJANGO_SETTINGS_MODULE', ' project  .settings')

_application = get_wsgi_application()

def application(environ, start_response):
os.environ['VAR1'] = environ.get('VAR1', '')
os.environ['VAR2'] = environ.get('VAR2', '')
return _application(environ, start_response)

In other words, just call get_wsgi_application() once outside of the function.

Graham

> On 10 Sep 2022, at 11:36 am, Juan Khawly  wrote:
> 
> Graham, 
> 
> It does click now. Couple of months ago, I had to modify the original wsgi.py 
> file to include Environmental variables read from my Virtual Host.
> 
> __
> I changed from: 
> 
> On wsgi.py
> 
> import os
> from django.core.wsgi import get_wsgi_application
> os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project.settings')
> application = get_wsgi_application()
> 
> to
> 
> On Virtual Host
> 
> SetEnv VAR1 
> SetEnv VAR2 
> 
> On wsgi.py
> 
> import os
> from django.core.wsgi import get_wsgi_application
> os.environ.setdefault('DJANGO_SETTINGS_MODULE', ' project  .settings')
> 
> def application(environ, start_response):
> os.environ['VAR1'] = environ.get('VAR1', '')
> os.environ['VAR2'] = environ.get('VAR2', '')
> _application = get_wsgi_application()
> return _application(environ, start_response)
> __
> 
> I think I found this solution on a forum and it worked and never expected 
> that it would yield on such consequences.
> 
> Do you have any suggestion on the right way to do this ? I remember testing 
> multiple options and this was the only one that worked.
> 
> Thanks,
> Juan Khawly
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Friday, September 9, 2022 at 4:46:42 PM UTC-4 Graham Dumpleton wrote:
> As logs show, you have a problem with thread locking related to logging 
> subsystem of Python.
> 
> What do you have in your wsgi.py file?
> 
> The messages suggest you are calling Django's get_wsgi_application() on every 
> request, which is a bad idea. It should only be called once at top level 
> scope in wsgi.py, not in a request handler function.
> 
> Graham
> 
> 
>> On 10 Sep 2022, at 2:41 am, Juan Khawly > > wrote:
>> 
> 
>> Graham,
>> 
>> After adding the timeout, as you said, the server auto recovers from the 
>> problem. 
>> 
>> After mod_wsgi is logging info level. My error log now gives traces of where 
>> the problem is. I'm attaching my error.log from today (sep 09),  any ideas? 
>> 
>> Thanks for the support.
>> Juan Khawly
>> 
>> On Wednesday, September 7, 2022 at 8:59:22 PM UTC-4 Juan Khawly wrote:
>> Makes total sense. 
>> 
>> Just added the option to the DaemonProcess and LogLevel info to the virtual 
>> host. I will be monitoring the the logs and report back in a couple days for 
>> reference.
>> 
>> Appreciate your help.
>> Juan Khawly
>> 
>> On Wednesday, September 7, 2022 at 6:30:17 PM UTC-4 Graham Dumpleton wrote:
>> 
>>> On 7 Sep 2022, at 11:43 pm, Juan Khawly > wrote:
>>> 
>>> Graham,
>>> 
>>> Going to make that change, monitor and keep this chat updated with the 
>>> result.
>>> 
>>> 2 Questions:
>>> 
>>> 1) The option request-timeout = 60 is included inside the virtual host 
>>> along with the rest of the Daemon code right ?
>> 
>> It is an option to be added to the existing WSGIDaemonProcess directive.
>> 
>>> 2) Under no traffic, do you have any idea of why this problem could happen? 
>>> As I explained, it is usually, but not always, preceded by couple of GET 
>>> Request from a random IP (bot requests) to random urls. My assumption was 
>>> Slow DDOS and this is why I enabled modreqtimeout, mod security and mod 
>>> qos. But at this point I'm clueless of how to diagnose.
>> 
>> No idea. If it was truly a slow DDOS attack the request wouldn't actually 
>> show in the access logs because Apache only logs requests on com

Re: [modwsgi] Apache server goes down multiple times a week

[Graham Dumpleton]

As logs show, you have a problem with thread locking related to logging 
subsystem of Python.

What do you have in your wsgi.py file?

The messages suggest you are calling Django's get_wsgi_application() on every 
request, which is a bad idea. It should only be called once at top level scope 
in wsgi.py, not in a request handler function.

Graham

> On 10 Sep 2022, at 2:41 am, Juan Khawly  wrote:
> 
> Graham,
> 
> After adding the timeout, as you said, the server auto recovers from the 
> problem. 
> 
> After mod_wsgi is logging info level. My error log now gives traces of where 
> the problem is. I'm attaching my error.log from today (sep 09),  any ideas? 
> 
> Thanks for the support.
> Juan Khawly
> 
> On Wednesday, September 7, 2022 at 8:59:22 PM UTC-4 Juan Khawly wrote:
> Makes total sense. 
> 
> Just added the option to the DaemonProcess and LogLevel info to the virtual 
> host. I will be monitoring the the logs and report back in a couple days for 
> reference.
> 
> Appreciate your help.
> Juan Khawly
> 
> On Wednesday, September 7, 2022 at 6:30:17 PM UTC-4 Graham Dumpleton wrote:
> 
>> On 7 Sep 2022, at 11:43 pm, Juan Khawly > wrote:
>> 
>> Graham,
>> 
>> Going to make that change, monitor and keep this chat updated with the 
>> result.
>> 
>> 2 Questions:
>> 
>> 1) The option request-timeout = 60 is included inside the virtual host along 
>> with the rest of the Daemon code right ?
> 
> It is an option to be added to the existing WSGIDaemonProcess directive.
> 
>> 2) Under no traffic, do you have any idea of why this problem could happen? 
>> As I explained, it is usually, but not always, preceded by couple of GET 
>> Request from a random IP (bot requests) to random urls. My assumption was 
>> Slow DDOS and this is why I enabled modreqtimeout, mod security and mod qos. 
>> But at this point I'm clueless of how to diagnose.
> 
> No idea. If it was truly a slow DDOS attack the request wouldn't actually 
> show in the access logs because Apache only logs requests on completion. So 
> am not sure one could say is related to those other requests. I would say it 
> is more likely that over time a trickle of requests come in to your 
> application as normal which block and slowly use up capacity. Hopefully the 
> stack trace created when get a forced restart due to request timeout will 
> show where. Just keep in mind that since the request timeout will cause auto 
> recovery you may not notice it occurred, so you will need to periodically 
> check Apache error logs yourself. Make sure that have info LogLevel for the 
> virtual host so get more useful information out of mod_wsgi.
> 
> 
>> Thanks
>> Juan Khawly
>> 
>> On Tuesday, September 6, 2022 at 6:04:39 PM UTC-4 Graham Dumpleton wrote:
>> Sorry, seems I didn't see your update.
>> 
>> Add an option:
>> 
>> request-timeout=60
>> 
>> to the WSGIDaemonProcess.
>> 
>> Set the value (in seconds) greater than you would expect your HTTP requests 
>> to normally run.
>> 
>> What will happen is that when the average running time for all possible 
>> concurrent requests exceeds that timeout value, the daemon process will be 
>> forcibly restarted. This will have the effect of unblocking the process and 
>> a new one will be started in its place. So acts as a fail safe to ensure 
>> your application keeps running.
>> 
>> What this will also do is attempt to dump out Python stack traces for what 
>> all the request handler threads were doing when the process is restarted. 
>> This will hopefully allow you to work out why your request handlers are 
>> getting stuck, be it they are getting stuck on a lock, or waiting on a 
>> backend service.
>> 
>> In short, your request handlers are getting stuck and not completing. Over 
>> time these are building up and the thread pool for handling requests is 
>> exhausted and so the process stops handling requests.
>> 
>> Graham
>> 
>> 
>>> On 7 Sep 2022, at 5:44 am, Juan Khawly > wrote:
>>> 
>> 
>>> Any ideas? 
>>> 
>>> Thanks
>>> 
>>> On Friday, September 2, 2022 at 8:47:47 AM UTC-4 Juan Khawly wrote:
>>> Hello Graham, 
>>> 
>>> I'm going to try to address your questions:
>>> 
>>> Inside my Virtual Host
>>> 
>>> Alias /static /data/home/user/project/frontend/build/static
>>> 
>>> Require all granted
>>> 
>>> 
>>> 
>>> 

Re: [modwsgi] Apache server goes down multiple times a week

[Graham Dumpleton]

> On 7 Sep 2022, at 11:43 pm, Juan Khawly  wrote:
> 
> Graham,
> 
> Going to make that change, monitor and keep this chat updated with the result.
> 
> 2 Questions:
> 
> 1) The option request-timeout = 60 is included inside the virtual host along 
> with the rest of the Daemon code right ?

It is an option to be added to the existing WSGIDaemonProcess directive.

> 2) Under no traffic, do you have any idea of why this problem could happen? 
> As I explained, it is usually, but not always, preceded by couple of GET 
> Request from a random IP (bot requests) to random urls. My assumption was 
> Slow DDOS and this is why I enabled modreqtimeout, mod security and mod qos. 
> But at this point I'm clueless of how to diagnose.

No idea. If it was truly a slow DDOS attack the request wouldn't actually show 
in the access logs because Apache only logs requests on completion. So am not 
sure one could say is related to those other requests. I would say it is more 
likely that over time a trickle of requests come in to your application as 
normal which block and slowly use up capacity. Hopefully the stack trace 
created when get a forced restart due to request timeout will show where. Just 
keep in mind that since the request timeout will cause auto recovery you may 
not notice it occurred, so you will need to periodically check Apache error 
logs yourself. Make sure that have info LogLevel for the virtual host so get 
more useful information out of mod_wsgi.

> Thanks
> Juan Khawly
> 
> On Tuesday, September 6, 2022 at 6:04:39 PM UTC-4 Graham Dumpleton wrote:
> Sorry, seems I didn't see your update.
> 
> Add an option:
> 
> request-timeout=60
> 
> to the WSGIDaemonProcess.
> 
> Set the value (in seconds) greater than you would expect your HTTP requests 
> to normally run.
> 
> What will happen is that when the average running time for all possible 
> concurrent requests exceeds that timeout value, the daemon process will be 
> forcibly restarted. This will have the effect of unblocking the process and a 
> new one will be started in its place. So acts as a fail safe to ensure your 
> application keeps running.
> 
> What this will also do is attempt to dump out Python stack traces for what 
> all the request handler threads were doing when the process is restarted. 
> This will hopefully allow you to work out why your request handlers are 
> getting stuck, be it they are getting stuck on a lock, or waiting on a 
> backend service.
> 
> In short, your request handlers are getting stuck and not completing. Over 
> time these are building up and the thread pool for handling requests is 
> exhausted and so the process stops handling requests.
> 
> Graham
> 
> 
>> On 7 Sep 2022, at 5:44 am, Juan Khawly > > wrote:
>> 
> 
>> Any ideas? 
>> 
>> Thanks
>> 
>> On Friday, September 2, 2022 at 8:47:47 AM UTC-4 Juan Khawly wrote:
>> Hello Graham, 
>> 
>> I'm going to try to address your questions:
>> 
>> Inside my Virtual Host
>> 
>> Alias /static /data/home/user/project/frontend/build/static
>> 
>> Require all granted
>> 
>> 
>> 
>> 
>> Require all granted
>> 
>> 
>> 
>> WSGIScriptAlias / /data/home/user/project/my_project/wsgi.py
>> WSGIDaemonProcess my_project python-path=/data/home/user/project 
>> python-home=/data/home/user/environment/venv
>> WSGIProcessGroup my_project
>> 
>> 
>> Inside apache2.conf
>> 
>> WSGIApplicationGroup %{GLOBAL}
>> 
>> On the apache/error.log
>> When I get the 503 on the access.log, these are the types of errors seen on 
>> the error.log
>> 
>> One type of error
>> [Thu Sep 01 04:22:21.520772 2022] [wsgi:error] [pid 3267:tid 
>> 140518453380864] [client 118.126.82.157:37722 
>> <http://118.126.82.157:37722/>] Timeout when reading response headers from 
>> daemon process 'my_project': /data/home/project/my_project/my_project/wsgi.py
>> 
>> Another type of error
>> [Thu Sep 01 04:27:00.053558 2022] [wsgi:error] [pid 3267:tid 
>> 140518595991296] (11)Resource temporarily unavailable: [client 
>> 172.31.17.102:31880 <http://172.31.17.102:31880/>] mod_wsgi (pid=3267): 
>> Unable to connect to WSGI daemon process ' my_project  ' on 
>> '/var/run/apache2/wsgi.2385.1.1.sock' after multiple attempts as listener 
>> backlog limit was exceeded or the socket does not exist.
>> 
>> 
>> 
>> Thanks,
>> Juan Khawly
>> 
&g

Re: [modwsgi] Apache server goes down multiple times a week

[Graham Dumpleton]

Sorry, seems I didn't see your update.

Add an option:

request-timeout=60

to the WSGIDaemonProcess.

Set the value (in seconds) greater than you would expect your HTTP requests to 
normally run.

What will happen is that when the average running time for all possible 
concurrent requests exceeds that timeout value, the daemon process will be 
forcibly restarted. This will have the effect of unblocking the process and a 
new one will be started in its place. So acts as a fail safe to ensure your 
application keeps running.

What this will also do is attempt to dump out Python stack traces for what all 
the request handler threads were doing when the process is restarted. This will 
hopefully allow you to work out why your request handlers are getting stuck, be 
it they are getting stuck on a lock, or waiting on a backend service.

In short, your request handlers are getting stuck and not completing. Over time 
these are building up and the thread pool for handling requests is exhausted 
and so the process stops handling requests.

Graham

> On 7 Sep 2022, at 5:44 am, Juan Khawly  wrote:
> 
> Any ideas? 
> 
> Thanks
> 
> On Friday, September 2, 2022 at 8:47:47 AM UTC-4 Juan Khawly wrote:
> Hello Graham, 
> 
> I'm going to try to address your questions:
> 
> Inside my Virtual Host
> 
> Alias /static /data/home/user/project/frontend/build/static
> 
> Require all granted
> 
> 
> 
> 
> Require all granted
> 
> 
> 
> WSGIScriptAlias / /data/home/user/project/my_project/wsgi.py
> WSGIDaemonProcess my_project python-path=/data/home/user/project 
> python-home=/data/home/user/environment/venv
> WSGIProcessGroup my_project
> 
> 
> Inside apache2.conf
> 
> WSGIApplicationGroup %{GLOBAL}
> 
> On the apache/error.log
> When I get the 503 on the access.log, these are the types of errors seen on 
> the error.log
> 
> One type of error
> [Thu Sep 01 04:22:21.520772 2022] [wsgi:error] [pid 3267:tid 140518453380864] 
> [client 118.126.82.157:37722 <http://118.126.82.157:37722/>] Timeout when 
> reading response headers from daemon process 'my_project': 
> /data/home/project/my_project/my_project/wsgi.py
> 
> Another type of error
> [Thu Sep 01 04:27:00.053558 2022] [wsgi:error] [pid 3267:tid 140518595991296] 
> (11)Resource temporarily unavailable: [client 172.31.17.102:31880 
> <http://172.31.17.102:31880/>] mod_wsgi (pid=3267): Unable to connect to WSGI 
> daemon process ' my_project  ' on '/var/run/apache2/wsgi.2385.1.1.sock' after 
> multiple attempts as listener backlog limit was exceeded or the socket does 
> not exist.
> 
> 
> 
> Thanks,
> Juan Khawly
> 
> On Thursday, September 1, 2022 at 5:54:43 PM UTC-4 Graham Dumpleton wrote:
> Would need to see the mod_wsgi configuration you are using to configure the 
> WSGI application, including how WSGIDaemonProcess is configured and whether 
> you are using WSGIApplicationGroup. Also, what errors are in the Apache error 
> log when the 503 errors occur.
> 
> 
>> On 2 Sep 2022, at 4:57 am, Juan Khawly > wrote:
>> 
> 
>> Hello,
>> 
>> I've been running into this problem for a while.
>> 
>> CONTEXT 
>> 
>> I have an application developed in python (3.10), django 4.0.3, using 
>> mod_wsgi and apache. The application is in a DEV environment and hosted in 
>> AWS EC2. Currently, it does not receive traffic at all. 
>> 
>> Installation of Mod WSGI
>> apt-get install -y apache2-dev
>> 
>> Setup out of the VENV
>> mod_wsgi-express install-module
>> 
>> editing: /etc/apache2/mods-available/wsgi.load
>> 
>> LoadModule wsgi_module 
>> "/usr/lib/apache2/modules/mod_wsgi-py310.cpython-310-x86_64-linux-gnu.so 
>> <http://mod_wsgi-py310.cpython-310-x86_64-linux-gnu.so/>"
>> WSGIPythonHome "/data/home/user/environment/venv"
>> 
>> Module Enabled
>> a2enmod wsgi
>> 
>> PROBLEM
>> 
>> The application works perfect most of the time. Couple of times a week, 
>> without traffic the apache server goes down into 503. Usually it is preceded 
>> by a random request but it does not always happen that way. I am assuming 
>> that is Slow DDOS but I want to make sure it is not miss configuration of 
>> the WSGI.
>> 
>> access.log example
> 
>> 
>> 
>> error.log example
>> I masked the internal routes
>> 
>> This is one of the errors:
>> [Thu Sep 01 04:22:21.520772 2022] [wsgi:error] [pid 3267:tid 
>> 14051845338

Re: [modwsgi] ImportError caused by wrong library path in flask app using WSGI daemon

[Graham Dumpleton]

Conda distributions of Python don't play nicely with embedded systems because 
they ship their own versions of common libraries which are also shipped with 
the operating system, but where the Conda version can be an incompatible 
version.

This causes problems when Python is being embedded in an application (Apache in 
this case), where the application (Apache) is already linking in the system 
version of the library.

Because the dynamic linker only looks at the shared library name, it will see 
that libz.so is already linked into the application process and use whatever 
that is, which will then not be the version your Python extension expects and 
will fail.

For Apache usually the problem is that you also have mod_php loaded into Apache 
and it is preloading a lot of PHP extensions which have references to some 
library which drags in the conflicting system library. This is a known issue 
with some graphics libraries such as libpng.so pulled in by PHP.

So the only real way around this in this case is not to load PHP into Apache if 
you don't need PHP to be enabled. Do that and it may then work.

If you must have PHP loaded into your primary Apache, then use mod_wsgi-express 
for your Python application instead and configure the front end Apache where 
PHP runs to proxy requests through to the mod_wsgi-express instance as 
necessary.

So try the following two things.

1. Try and run your application using mod_wsgi-express instead of your primary 
Apache instance and see if that works.
2. Disable PHP in your primary Apache instance, completely stop Apache and 
start it again (not just a reload), and see if it then works.

Graham

> On 6 Sep 2022, at 3:31 am, Nathan Wendt  wrote:
> 
> I have a flask application that is run on apache using mod_wsgi. I have a 
> python environment that I set up using miniconda. Initially, mod_wsgi was 
> installed using conda. Using a mod_wsgi daemon process with a properly set 
> python-home, I was able to run a very basic "hello, world" app to verify 
> things were working properly. I then began to add pieces to the app to 
> process data and output images. I began to see ImportError in the apache logs 
> when trying to run the app. The specific error was:
> 
> ImportError: /lib64/libz.so.1: version `ZLIB_1.2.9` not found (required by 
> ~/miniconda3/envs/.../libpng16.so.16)
> 
> This error is triggered by importing the rasterio package (which depends on 
> GDAL, which needs libpng). When I look at the libpng referred to by the error 
> with ldd, however, it is properly linked to the libz that is in the conda 
> environment. Somehow the library path only includes the system paths within 
> the daemon process. If I am to use my conda environment python on the command 
> line to import rasterio, no such error occurs. It only occurs within the 
> flask app. I next built mod_wsgi from source using the conda environment 
> python just to be sure I was having that all linked correctly. The same error 
> still occurred in the app. When checking the sys.path from within the app, 
> that all looks appropriate as well.
> 
> Just based on what I am seeing, it seems like something is going on 
> specifically with the mod_wsgi daemon process. Do I need to set something 
> other than just python-home? There is an SO question with a very similar 
> issue 
> (https://stackoverflow.com/questions/33497639/why-is-wsgi-looking-for-a-library-in-lib64-when-the-correct-version-is-in-the-p),
>  but the proposed solution seems like bad practice to me. I am hoping someone 
> has an idea of what might be happening here.
> 
> mod_wsgi: 4.9.3
> apache: 2.4.6
> python: 3.10.6
> flask: 2.2.2
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/9dd85566-ec3f-42f4-bfe3-3032e6d486den%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/376B7435-5115-422E-8D8E-2D7DC613F631%40gmail.com.

Re: [modwsgi] Apache server goes down multiple times a week

[Graham Dumpleton]

Would need to see the mod_wsgi configuration you are using to configure the 
WSGI application, including how WSGIDaemonProcess is configured and whether you 
are using WSGIApplicationGroup. Also, what errors are in the Apache error log 
when the 503 errors occur.

> On 2 Sep 2022, at 4:57 am, Juan Khawly  wrote:
> 
> Hello,
> 
> I've been running into this problem for a while.
> 
> CONTEXT 
> 
> I have an application developed in python (3.10), django 4.0.3, using 
> mod_wsgi and apache. The application is in a DEV environment and hosted in 
> AWS EC2. Currently, it does not receive traffic at all. 
> 
> Installation of Mod WSGI
> apt-get install -y apache2-dev
> 
> Setup out of the VENV
> mod_wsgi-express install-module
> 
> editing: /etc/apache2/mods-available/wsgi.load
> 
> LoadModule wsgi_module 
> "/usr/lib/apache2/modules/mod_wsgi-py310.cpython-310-x86_64-linux-gnu.so"
> WSGIPythonHome "/data/home/user/environment/venv"
> 
> Module Enabled
> a2enmod wsgi
> 
> PROBLEM
> 
> The application works perfect most of the time. Couple of times a week, 
> without traffic the apache server goes down into 503. Usually it is preceded 
> by a random request but it does not always happen that way. I am assuming 
> that is Slow DDOS but I want to make sure it is not miss configuration of the 
> WSGI.
> 
> access.log example
> 
> 
> error.log example
> I masked the internal routes
> 
> This is one of the errors:
> [Thu Sep 01 04:22:21.520772 2022] [wsgi:error] [pid 3267:tid 140518453380864] 
> [client 118.126.82.157:37722] Timeout when reading response headers from 
> daemon process 'X': /XXX//X/X/XX/wsgi.py
> 
> Another type of error:
> [Thu Sep 01 04:22:21.520772 2022] [wsgi:error] [pid 3267:tid 140518453380864] 
> [client 118.126.82.157:37722] Timeout when reading response headers from 
> daemon process 'XXX': /XXX//X/XX/XXX/wsgi.py
> 
> SOLUTION 
> 
> If I restart the server, all works again until next failure.
> 
> I've enabled the following modules, in case it is SlowDDOS
> modreqtimeout
> libapache2-mod-qos
> libapache2-mod-security2.
> 
> Any recommendation?
> 
> Thanks,
> Juan Khawly
> 
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/3cc5285a-9943-4143-9b7f-5fa24e681c70n%40googlegroups.com
>  
> .
> 

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/69A7D660-DCCC-4779-8F51-78CCB0376895%40gmail.com.

Re: [modwsgi] WSGI error Truncated or oversized response headers received from daemon process

[Graham Dumpleton]

Are you using system packages for Python, or are you creating a Python virtual 
environment and installing all packages yourself using pip or other Python 
package manager?

Even if the latter, what could have happened is that a system library for a 
package, eg., PostgreSQL, could have been updated and so a Python package which 
gets compiled from source (as has an extension could need rebuilding and 
reinstalling).

Anyway, it is going to be really hard to work out unless you can narrow it done 
as occurring in specific Python code.

Can you ask your server admins if they have saving of core dump files enabled 
and thus whether there is a core dump from Apache which they could extract a 
core dump stack trace from? I have no idea what Ubuntu requires to save core 
dumps.

Other than that, can only suggest you recreate you Python virtual environment 
with all the packages. When running pip ensure you use the --no-cache-dir 
option so that it rebuilds extensions again against latest system libraries and 
doesn't use old cache builds compiled against older system libraries.

Graham

> On 25 Aug 2022, at 8:46 am, Jose Luis Arrioja  
> wrote:
> 
> Did it only happen the once, or is it reproducible?
> If you are asking me, the problem is persistent?, yes, I no longer have 
> access to my project, if it is about updating packages command, the server 
> admin tells me that command execute daily.
> 
> About the memory, I don't know, because I don't see anything like 'Out of 
> memory allocated' in the Apache logs recently:
> 
> 
> 
> Thanks for the help, I don't know much about wsgi.
> 
> El miércoles, 24 de agosto de 2022 a las 16:58:41 UTC-5, Graham Dumpleton 
> escribió:
> Nope. The problematic Apache version is 2.4.54. If that truly is the version 
> you have it is very old.
> 
> Did it only happen the once, or is it reproducible?
> 
> Could you have run out of memory on the system?
> 
> 
>> On 25 Aug 2022, at 7:36 am, Jose Luis Arrioja > > wrote:
>> 
> 
>> Apparently yes, the server updates packages daily
>> Server version: Apache/2.4.29 (Ubuntu)
>> 
>> Server built:   2022-06-23T12:51:37
>> 
>> Do you think that could be the reason?
>> 
>> 
>> El miércoles, 24 de agosto de 2022 a las 15:18:46 UTC-5, Graham Dumpleton 
>> escribió:
>> Did you by chance just update to latest Apache version?
>> 
>> Is it occurring when a POST request is done with content over 1Gi in size?
>> 
>> What other updates to packages have you done recently?
>> 
>> Graham
>> 
>> 
>>> On 25 Aug 2022, at 6:16 am, Jose Luis Arrioja >> <>> wrote:
>>> 
>> 
>>> Hi,
>>> Recently, my project report a 'Truncated or oversized response headers 
>>> received from daemon process' out of nowhere after 3 years of working fine. 
>>> This is what apache logs show up:
>>> [wsgi:info] [pid 8691:tid 139935800280832] [remote 
>>> 2806:10be:a:1253:c80c:b395:242c:5334:4326] mod_wsgi (pid=8691, 
>>> process='MyProject', application=''): Loading WSGI script 
>>> '/home/axel/MyProjectProject/MyProject/MyProject/wsgi.py'.
>>> [core:notice] [pid 7681:tid 139935929101248] AH00051: child pid 8642 exit 
>>> signal Segmentation fault (11), possible coredump in /etc/apache2
>>> [wsgi:info] [pid 8718:tid 139935929101248] mod_wsgi (pid=8718): Attach 
>>> interpreter ''.
>>> [wsgi:info] [pid 8718:tid 139935929101248] mod_wsgi (pid=8718): Adding 
>>> '/home/axel/MyProjectProject/MyProject' to path.
>>> [wsgi:error] [pid 7891:tid 139935646435072] [client 
>>> 2806:10be:a:1253:c80c:b395:242c:5334:4326] Truncated or oversized response 
>>> headers received from daemon process 'MyProject': 
>>> /home/axel/MyProjectProject/MyProject/MyProject/wsgi.py, referer: 
>>> https://MyProject.net/es/login/ <https://myproject.net/es/login/>
>>> 
>>> I check a few solutions for this in serverfault or Stack Overflow and I add 
>>> some new things for my Apache conf like 'WSGIApplicationGroup %{GLOBAL}' or 
>>> 'processes=5 threads=15 display-name=%{GROUP} user=www-data group=www-data' 
>>> in WSGIDaemonProcess but nothing works (of course I restart Apache service 
>>> every time I change something).
>>> 
>>> 
>>> 
>>> DocumentRoot /var/www/html
>>> ServerAlias MyProject.net <http://myproject.net/>
>>> ServerAlias www.MyProject.net <http://www.myproject.net/>
>>> LogLevel info ssl:warn
&g

Re: [modwsgi] WSGI error Truncated or oversized response headers received from daemon process

[Graham Dumpleton]

Nope. The problematic Apache version is 2.4.54. If that truly is the version 
you have it is very old.

Did it only happen the once, or is it reproducible?

Could you have run out of memory on the system?

> On 25 Aug 2022, at 7:36 am, Jose Luis Arrioja  
> wrote:
> 
> Apparently yes, the server updates packages daily
> Server version: Apache/2.4.29 (Ubuntu)
> 
> Server built:   2022-06-23T12:51:37
> 
> Do you think that could be the reason?
> 
> 
> El miércoles, 24 de agosto de 2022 a las 15:18:46 UTC-5, Graham Dumpleton 
> escribió:
> Did you by chance just update to latest Apache version?
> 
> Is it occurring when a POST request is done with content over 1Gi in size?
> 
> What other updates to packages have you done recently?
> 
> Graham
> 
> 
>> On 25 Aug 2022, at 6:16 am, Jose Luis Arrioja > > wrote:
>> 
> 
>> Hi,
>> Recently, my project report a 'Truncated or oversized response headers 
>> received from daemon process' out of nowhere after 3 years of working fine. 
>> This is what apache logs show up:
>> [wsgi:info] [pid 8691:tid 139935800280832] [remote 
>> 2806:10be:a:1253:c80c:b395:242c:5334:4326] mod_wsgi (pid=8691, 
>> process='MyProject', application=''): Loading WSGI script 
>> '/home/axel/MyProjectProject/MyProject/MyProject/wsgi.py'.
>> [core:notice] [pid 7681:tid 139935929101248] AH00051: child pid 8642 exit 
>> signal Segmentation fault (11), possible coredump in /etc/apache2
>> [wsgi:info] [pid 8718:tid 139935929101248] mod_wsgi (pid=8718): Attach 
>> interpreter ''.
>> [wsgi:info] [pid 8718:tid 139935929101248] mod_wsgi (pid=8718): Adding 
>> '/home/axel/MyProjectProject/MyProject' to path.
>> [wsgi:error] [pid 7891:tid 139935646435072] [client 
>> 2806:10be:a:1253:c80c:b395:242c:5334:4326] Truncated or oversized response 
>> headers received from daemon process 'MyProject': 
>> /home/axel/MyProjectProject/MyProject/MyProject/wsgi.py, referer: 
>> https://MyProject.net/es/login/ <https://myproject.net/es/login/>
>> 
>> I check a few solutions for this in serverfault or Stack Overflow and I add 
>> some new things for my Apache conf like 'WSGIApplicationGroup %{GLOBAL}' or 
>> 'processes=5 threads=15 display-name=%{GROUP} user=www-data group=www-data' 
>> in WSGIDaemonProcess but nothing works (of course I restart Apache service 
>> every time I change something).
>> 
>> 
>> 
>> DocumentRoot /var/www/html
>> ServerAlias MyProject.net <http://myproject.net/>
>> ServerAlias www.MyProject.net <http://www.myproject.net/>
>> LogLevel info ssl:warn
>> 
>> Alias /res /home/axel/MyProjectProject/MyProject/res
>> 
>> Require all granted
>> 
>> 
>> Alias /media /home/axel/MyProjectProject/MyProject/media
>> 
>> Require all granted
>> 
>> 
>> 
>> 
>> Require all granted
>> 
>> 
>> 
>> 
>> 
>> Require all granted
>> 
>> 
>> 
>> WSGIDaemonProcess MyProject 
>> python-home=/home/axel/MyProjectProject/MyProjectVenv 
>> python-path=/home/axel/MyProjectProject/MyProject processes=5 threads=15 
>> display-name=%{GROUP} user=www-data group=www-data
>> WSGIApplicationGroup %{GLOBAL}
>> #WSGIProcessGroup %{GLOBAL}
>> WSGIProcessGroup MyProject
>> WSGIScriptAlias / /home/axel/MyProjectProject/MyProject/MyProject/wsgi.py
>> 
>> RewriteEngine on
>> 
>> 
>> 
>> This is the list of dependency in Django:
>> 
>> Package Version  
>> 
>> --- -
>> 
>> certifi 2018.4.16
>> 
>> chardet 3.0.4
>> 
>> coreapi 2.3.3
>> 
>> coreschema  0.0.4
>> 
>> Django  2.0.5
>> 
>> django-filter   1.1.0
>> 
>> django-rest-swagger 2.2.0
>> 
>> django-rosetta  0.8.1
>> 
>> djangorestframework 3.8.2
>> 
>> html5lib1.0.1
>> 
>> httplib20.11.3   
>> 
>> idna2.7  
>> 
>> itypes  1.1.0
>> 
>> Jinja2  2.10 
>> 
>> lxml4.2.5
>> 
>> MarkupSafe  1.0  
>> 
>> microsofttranslator 0.8  
>> 
>> openapi-codec

Re: [modwsgi] WSGI error Truncated or oversized response headers received from daemon process

[Graham Dumpleton]

Did you by chance just update to latest Apache version?

Is it occurring when a POST request is done with content over 1Gi in size?

What other updates to packages have you done recently?

Graham

> On 25 Aug 2022, at 6:16 am, Jose Luis Arrioja  
> wrote:
> 
> Hi,
> Recently, my project report a 'Truncated or oversized response headers 
> received from daemon process' out of nowhere after 3 years of working fine. 
> This is what apache logs show up:
> [wsgi:info] [pid 8691:tid 139935800280832] [remote 
> 2806:10be:a:1253:c80c:b395:242c:5334:4326] mod_wsgi (pid=8691, 
> process='MyProject', application=''): Loading WSGI script 
> '/home/axel/MyProjectProject/MyProject/MyProject/wsgi.py'.
> [core:notice] [pid 7681:tid 139935929101248] AH00051: child pid 8642 exit 
> signal Segmentation fault (11), possible coredump in /etc/apache2
> [wsgi:info] [pid 8718:tid 139935929101248] mod_wsgi (pid=8718): Attach 
> interpreter ''.
> [wsgi:info] [pid 8718:tid 139935929101248] mod_wsgi (pid=8718): Adding 
> '/home/axel/MyProjectProject/MyProject' to path.
> [wsgi:error] [pid 7891:tid 139935646435072] [client 
> 2806:10be:a:1253:c80c:b395:242c:5334:4326] Truncated or oversized response 
> headers received from daemon process 'MyProject': 
> /home/axel/MyProjectProject/MyProject/MyProject/wsgi.py, referer: 
> https://MyProject.net/es/login/
> 
> 
> I check a few solutions for this in serverfault or Stack Overflow and I add 
> some new things for my Apache conf like 'WSGIApplicationGroup %{GLOBAL}' or 
> 'processes=5 threads=15 display-name=%{GROUP} user=www-data group=www-data' 
> in WSGIDaemonProcess but nothing works (of course I restart Apache service 
> every time I change something).
> 
> 
> 
> DocumentRoot /var/www/html
> ServerAlias MyProject.net
> ServerAlias www.MyProject.net
> LogLevel info ssl:warn
> 
> Alias /res /home/axel/MyProjectProject/MyProject/res
> 
> Require all granted
> 
> 
> Alias /media /home/axel/MyProjectProject/MyProject/media
> 
> Require all granted
> 
> 
> 
> 
> Require all granted
> 
> 
> 
> 
> 
> Require all granted
> 
> 
> 
> WSGIDaemonProcess MyProject 
> python-home=/home/axel/MyProjectProject/MyProjectVenv 
> python-path=/home/axel/MyProjectProject/MyProject processes=5 threads=15 
> display-name=%{GROUP} user=www-data group=www-data
> WSGIApplicationGroup %{GLOBAL}
> #WSGIProcessGroup %{GLOBAL}
> WSGIProcessGroup MyProject
> WSGIScriptAlias / /home/axel/MyProjectProject/MyProject/MyProject/wsgi.py
> 
> RewriteEngine on
> 
> 
> 
> This is the list of dependency in Django:
> 
> Package Version  
> 
> --- -
> 
> certifi 2018.4.16
> 
> chardet 3.0.4
> 
> coreapi 2.3.3
> 
> coreschema  0.0.4
> 
> Django  2.0.5
> 
> django-filter   1.1.0
> 
> django-rest-swagger 2.2.0
> 
> django-rosetta  0.8.1
> 
> djangorestframework 3.8.2
> 
> html5lib1.0.1
> 
> httplib20.11.3   
> 
> idna2.7  
> 
> itypes  1.1.0
> 
> Jinja2  2.10 
> 
> lxml4.2.5
> 
> MarkupSafe  1.0  
> 
> microsofttranslator 0.8  
> 
> openapi-codec   1.3.2
> 
> Pillow  5.1.0
> 
> pip 18.1 
> 
> pkg-resources   0.0.0
> 
> polib   1.1.0
> 
> psycopg2-binary 2.7.4
> 
> PyPDF2  1.26.0   
> 
> python-docx 0.8.7
> 
> pytz2018.5   
> 
> reportlab   3.5.6
> 
> requests2.19.1   
> 
> setuptools  39.0.1   
> 
> simplejson  3.16.0   
> 
> six 1.11.0   
> 
> uritemplate 3.0.0
> 
> urllib3 1.23 
> 
> webencodings0.5.1
> 
> xhtml2pdf   0.2.2
> 
> XlsxWriter  3.0.1  
> 
> I'm not using PHP or anything, is just Django, PostgreSQL and javascript
> 
> Please provide solution for above issue, and sorry for my awful english
> 
> Thanks
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/89f4f197-da11-4559-bb0e-4b27d68d3299n%40googlegroups.com
>  
> .

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion

Re: [modwsgi] Q: Double-encoded environment variables?

[Graham Dumpleton]

I don't know what "raw_unicode_escape" is. In mod_wsgi, as per WSGI spec at 
time, it converts as Latin-1 (ISO-8859-1). If "raw_unicode_escape" is an alias 
for that then fine, but "raw_unicode_escape" never existed back long ago.

Seems it isn't quite the same.

raw_unicode_escape
Latin-1 encoding with \u and \U for other code points. Existing 
backslashes are not escaped in any way. It is used in the Python pickle 
protocol.

I would stick with plain Latin-1.

> On 18 Aug 2022, at 7:25 pm, 'albrecht.dr...@arcor.de' via modwsgi 
>  wrote:
> 
> Hi Graham:
> 
> Graham Dumpleton schrieb am Donnerstag, 18. August 2022 um 10:58:23 UTC+2:
> [snip] 
> Now it wasn't practical in Python 3 to pass through variables as byte strings 
> as the range of operations you could do on byte strings was very limited. 
> Thus the rule for WSGI under Python 3 was that the WSGI server was required 
> to take the underlying byte stream and convert it to the unicode capable 
> default string as ISO-8859-1 (Latin-1). It was then up to the WSGI 
> application to convert that to another string with the correct encoding. 
> Since it was a unicode string at that point, to do that it would need to do.
> 
>  Ah!  That fully explains the effect I observe!  As Apache passes the 
> environment as UTF-8, actually every value in it is double-encoded, right?
> 
> value.encode('ISO-8859-1').decode('UTF-8')
> 
> Not sure if it makes any difference in practice, but IMHO
> 
> value.encode('raw_unicode_escape').decode('utf-8')
> 
> might be more appropriate.  At least it works fine with mixed input from 
> different code pages (I added greek, cyrillic and hiragana chars to the 
> latin1 one).
> 
> Thanks again for your help!
> 
> Best, Albrecht.
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/c46d8d94-c59c-4dec-832a-8859a49764a0n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/modwsgi/c46d8d94-c59c-4dec-832a-8859a49764a0n%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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/96CDD292-58FE-4C12-B70C-C8207EAAE708%40gmail.com.