Your only choice would be to compile mod_wsgi from source code then. I know of no reason why latest source code wouldn’t work on older OS version. Your Apache version should be knew enough.
That means uninstalling the yum package for mod_wsgi and and tweaking Apache configuration to load the mod_wsgi module subsequently installed from source code. Graham > On 16 Feb 2016, at 3:52 AM, [email protected] wrote: > > I think our OS is Scientific Linux 6.1 - which is pretty old. Is there a way > to find out what the "newest" mod_wsgi module will work on it? doing a "yum > info mod_wsgi" returns version 3.2 as the latest mod_wsgi package. > > On Friday, February 12, 2016 at 2:45:31 PM UTC-6, Graham Dumpleton wrote: > >> On 13 Feb 2016, at 5:58 AM, [email protected] <javascript:> wrote: >> >> Today we received an alert from our alert system that the website was down. >> I've read some topics in here related to this problem but I wanted to >> provide some information of my configuration, and also see if anyone has any >> more insight on this problem. I'm running the website using web2py 2.8.2 and >> apache 2.2.15 with mod_wsgi 3.2. We've also got apache serving some PHP apps. >> >> Here's the related error that appeared the time the website was down: >> >> [Fri Feb 12 00:58:05 2016] [error] [client 195.159.183.42] Script timed out >> before returning headers: wsgihandler.py, referer: https://www.google.no >> <https://www.google.no/> >> >> Then I also noticed this: >> >> [Fri Feb 12 01:51:41 2016] [error] server reached MaxClients setting, >> consider raising the MaxClients setting >> [Fri Feb 12 01:52:14 2016] [info] Initial (No.1) HTTPS request received for >> child 255 (server servername:443) >> >> Not sure if the above is just symptomatic of the wsgihandler.py not >> returning requests. But it stopped at 255 so I'm guessing MaxClients is set >> at 256. >> >> Here's the current apache config: >> >> WSGIDaemonProcess web2py user=webadmin group=webadmin processes=3 threads=5 >> display-name=%{GROUP} maximum-requests=1000 >> >> I'm going to next set the inactivity-timeout=600 to see if it can restart >> itself... if this problem occurs again. Any more insight on how to track >> down this issue is much appreciated. > > Any chance you can upgrade mod_wsgi version? > > That version is ancient, unsupported and if not patched by the OS > distribution has a security vulnerability in it. More recent versions have > better inbuilt features for detecting blocked requests and dumping out > information about where they are stuck. A different timeout option will need > to be set to enable that though. > > 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 [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
