ramkrishanbhatt / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

Crashes with Apache 2.2.21 #258

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Please have a look at https://bugs.gentoo.org/show_bug.cgi?id=401225.

Original issue reported on code.google.com by djc.ochtman on 17 Feb 2012 at 7:53

GoogleCodeExporter commented 8 years ago
I recollect I helped someone with this issue separately and there problem went 
away after I got them to do some things. I think I help them out on IRC and 
they specifically referenced that issue.

Original comment by Graham.Dumpleton@gmail.com on 17 Feb 2012 at 7:59

GoogleCodeExporter commented 8 years ago
IRC LOG.

hi!
Why does such a crash happen? https://bugs.gentoo.org/show_bug.cgi?id=401225    
jotik
jotik: Third party C extension module for Python that isn't implemented to work 
in a Python sub interpreter.
jotik: If just the one application, add 'WSGIApplicationGroup %{GLOBAL}'.
jotik: Also make sure you are loading mod_python into same Apache.
Whoops.
Make sure you ARE NOT loading mod_python into same Apache.  

GrahamDumpleton: 1) what do you mean by "Third party C extension module for 
Python"
GrahamDumpleton: 2) having it loaded or not makes no difference.    
jotik
Any Python module/package from outside of main Python distribution which has a 
C code component.
Read 
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_St
ate_API 

I removed mod_python and all other wsgi applications from apache, and added 
'WSGIApplicationGroup %{GLOBAL}' to the VirtualHost configuration, but I still 
get HTTP 500. 
jotik
jotik: A 500 or a crash? Are you running daemon mode and you mean daemon mode 
process crashed, with Apache child then supplying a 500 response.
If not daemon and get 500, then would be different issue as hasn't actually 
crashed.    

GrahamDumpleton: just tried  both daemon and without. HTTP 500 with both.
I'm not sure whether it is the same issue as in the bug, since I don't know how 
to get a backtrace from it. 
jotik
jotik: What is the actual error messages in Apache error log then? What 
app/framework are you running?

GrahamDumpleton: I get no errors in apache logs, no hints even with LogLevel 
Debug
My framework is flask   
jotik
You need to find out how you can enable debug in Flask then. It likely is 
generating a 500 but it will not log details without debug on. Ask how to 
enable debug for Flask under mod_wsgi on #pocoo.
I can't remember how you do it. 

app.run(debug=True) or something like that?
jotik
jotik: Are you using that now?

yes.
jotik
The only other thing can think of where can get 500 and no message in either 
main Apache error log or virtual host, is where ErrorDocument directive set in 
Apache config to custom 500 error page.
If Flask though mounted at / and ErrorDocument URL a sub URL of that then Flask 
will not now about custom error document and return a 404.
Apache will then get confused about not being able to find a error document to 
use and will return generic 500.
See if you have:
# Multi-language error messages
#Include /private/etc/apache2/extra/httpd-multilang-errordoc.conf
uncommented rather than commented out.
Or otherwise look for ErrorDocument directive in Apache configuration.  

GrahamDumpleton: I found the error.
At least one of them.
debug wasn't on.
this doesn't turn on debug for wsgi: if __name__ == '__main__': 
app.run(debug=True)
I needed to do: app.debug = True    
jotik
Yeah. That is why can never remember. Is non obvious and never used to be 
documented. Is it documented now?

I can't remember either.
But I still had crashes before. Let me check whether I can reproduce.
GrahamDumpleton: Do I need to take some special care when running different 
wsgi applications under different vhosts?   
jotik
jotik: Especially if already needing to set WSGIApplicationGrouop to %{GLOBAL}, 
create a daemon process group for each application and have them run in 
separate processes. Then force them to run in main interpreter of each of those 
processes using that WSGIApplicationGroup directive.

GrahamDumpleton: thanks you a lot.
I got my apps running again.
I'm not sure what those aborts might have been about, but I'm currently not 
getting them any more. Maybe because I removed mod_python.  
jotik

Original comment by Graham.Dumpleton@gmail.com on 17 Feb 2012 at 8:36

GoogleCodeExporter commented 8 years ago
So basically, they should stop loading mod_python?

Original comment by djc.ochtman on 17 Feb 2012 at 8:47

GoogleCodeExporter commented 8 years ago
It was either mod_python, or that they were using a third party C extension 
module which doesn't like sub interpreters. Because they did both changes not 
sure which was cause, but don't suspect mod_wsgi or Apache builds as issue.

Original comment by Graham.Dumpleton@gmail.com on 17 Feb 2012 at 9:11

GoogleCodeExporter commented 8 years ago
not loading mod_python is a possible work-around. I had both loaded under the 
previous versions of apache without issue for at least a couple years. Issue 
only came up after recent upgrade to apache. I'll try and check not loading 
mod_python  next week when I have more bandwidth. 

Original comment by jonnyk...@gmail.com on 17 Feb 2012 at 5:39

GoogleCodeExporter commented 8 years ago
Closing with no action being taken. Believed to be an issue with users 
environment.

Original comment by Graham.Dumpleton@gmail.com on 19 Mar 2012 at 10:34