Differentiate between Django dev server and apache - django

easy question:
In my settings file, I want to set a constant depending on whether I am running from the dev server or Apache.
Any elegant way of doing this?
I am running with mod_wsgi

Use:
try:
from mod_wsgi import version as MOD_WSGI_VERSION
except ImportError:
MOD_WSGI_VERSION = None
if MOD_WSGI_VERSION:
... running mod_wsgi

Related

Django Webfaction 'Timeout when reading response headers from daemon process'

My Django app on my production server hosted on Webfaction was working fine until I just tried to restart it after pushing a change to the settings.py file. I ran
apache2/bin/restart
as usual. Then I tried to access my app on my browser, and I got a 504 Gateway timeout. I looked into the mod_wsgi logs and saw this:
[Thu Nov 03 23:46:53.605625 2016] [wsgi:error] [pid 8027:tid 139641332168448]
[client 127.0.0.1:34570] Timeout when reading response headers from daemon
process 'myapp' : /home/<me>/webapps/<myapp>/<ProjectName>/<myapp>/wsgi.py
What does this mean and how do I fix it? The only thing I changed in the settings.py file was moving some variable names around. I can still successfully interact with the app with
python2.7 manage.py shell
But I can't get to it on the web, nor use the API.
EDIT: Here's my wsgi.py file:
import os
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "<myapp>.settings")
application = get_wsgi_application()
Python C extension modules, like numpy, are known to cause timeouts when used under mod_wsgi. There's a clear explanation of the problem (direct from the author of mod_wsgi) available at https://serverfault.com/a/514251/109598
If that sounds like it might be the cause of your problem, then the solution is probably simple - add the following to your httpd.conf:
WSGIApplicationGroup %{GLOBAL}
Be sure to restart your Apache instance after making that change.
Try increasing Timeout directive in httpd.conf, which defaults to 60 seconds in Apache 2.4. For example:
TimeOut 600
Here is how I was able to find the root cause of my issue.
python manage.py showmigrations
My app could not reach the database server, so it would eventually time out. Running manage.py I could see see the error message on the console.
In my case (Python 3.6), the mimetypes module caused this problem. I did not further investigate this, but removing a call to mimetypes.guess_type solved the problem. The call was made in the related Django view function.
I hit the same problem because the home directory of the user under which the wsgi process was running had became unavailable at some point during the server upgrade.
This might help someone.
Thank you to lenhhoxung who in the comments to one of the other solutions mentioned upgrading server capabilities. I had been successfully running a demo site on an AWS EC2 Nano instance for a long time, but for some reason it suddenly started erroring out on one page that has some complex computations. I upgraded it to an AWS EC2 Micro instance, problem solved. I think this is worthy of its own answer here considering this took a good chunk of a day. All credit to lenhhoxung, though! Thanks!

BeautifulSoup inside Django view makes WSGI timeout

For a strange reason when I instantiate a BeautifulSoup object inside Django's view, the WSGI timeout. Any help is appreciated as I am banging my head against the wall for hours and cannot find the root of this problem.
The view:
def index(request):
soup = BeautifulSoup('<b>Bold</b>') # Removing this line solve the proble
return HttpResponse('Hello')
The error message in Apache log:
[wsgi:error] [pid 4014] [client 127.0.0.1:50892] Timeout when reading response headers from daemon process 'test.local': /htdocs/test/test/wsgi.py
Update: This seems to be a bug in BeautifulSoup, however there is no soution.
Various third party packages for Python which use C extension modules, and this includes scipy, numpy and Beautifulsoup, will only work in the Python main interpreter and cannot be used in sub interpreters as mod_wsgi by default uses. You can find that in below link.
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
You can solve this by writing below line in your conf file.
WSGIApplicationGroup %{GLOBAL}
If running multiple WSGI applications on same server, you would want to start investigating using daemon mode because some frameworks don't allow multiple instances to run in same interpreter. This is the case with Django. Thus use daemon mode so each is in its own process and force each to run in main interpreter of their respective daemon mode process groups.

WSGI loads settings of the wrong project: how to debug?

I have two django based web applications on the same server.
One of them i'll call CORRECT_PROJECT and the other one WRONG_PROJECT
The last one, CORRECT_PROJECT, is installed using a virtual environment and uses a different version of django (1.4). There's a very strange problem: sometimes, usually after a log out or an email confirmation (but sometimes looks just random!), the server returns a 500 internal server error and the error log says
"Could not import settings 'WRONG_PROJECT.settings' (Is it on sys.path?): No module name WRONG_PROJECT.settings, refer: CORRECT_PROJECT/URL"
That is, by loading CORRECT_PROJECT, sometimes the system (WSGI? Apache? Django?) tries to load the settings from WRONG_PROJECT.
By hitting refresh aggressively the error disappears.
What could be wrong? How can I debug?
CORRECT_PROJECT uses WSGI in deamon mode.
Solution
Use deamon mode: http://modwsgi.readthedocs.org/en/latest/configuration-directives/WSGIDaemonProcess.html
You are using wsgi.py from Django 1.4. That will not work when hosting multiple web apps in the same process.
Best solution is to use daemon mode and delegate each to a distinct daemon process group.
If can't do that, change the wsgi.py files of both so they do not use:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")
but instead use:
os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"
Change mysite.settings as necessary.

Getting mod_geoip to work with mod_wsgi in Apache 2.2.17

I'd like to access the GEOIP_COUNTRY_CODE environment variable from within Django running on mod_wsgi in daemon mode. The problem is, I can see the variable from within PHP scripts running on the server but it seems that it is not passed through WSGI to my Django site.
request.META.get('GEOIP_COUNTRY_CODE') does not work.
Is there something like WSGIPassAuthorization for additional environment variables in mod_wsgi?
If the variable is set by the extension module as an environment variable, then it will be accessible as:
import os
value = os.environ['GEOIP_COUNTRY_CODE']
Ie., just like any other environment variable.
UPDATE 1:
If set inside of an Apache module however such as mod_geoip, the only way it would be transfered into WSGI application realm is if it is set in req.subprocess_env of Apache request structure. Ie., the same as if SetEnv directive had been used with Apache. In that case it should appear in the WSGI environ dictionary passed to the WSGI application.
To try and validate whether this is occuring, using WSGI echo test script shown in:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_Request_Environment

Works using Django development server, but throws import error with Apache using mod_wsgi

I have a Django project that works fine with the development server that comes with it.
No errors are produced at all when I use "django manage.py runserver" and the app works fine, but when I try to use it with mod_wsgi and Apache the browser displays "Internal Server Error" with a 500 error code and it generates an import error in the Apache error log.
Here's the error in the log:
ImportError: No module named registration
I'm using the Django registration module which is located in a path like this:
/opt/raj/photos/registration
I know that the registration app is in the path because I can fire up a Python shell, import sys, and get a list of paths using sys.path.
Here are some of the paths output from Python shell:
sys.path
['', '/opt/raj/pyamf', '/opt/raj', '/opt/raj/pictures', '/opt/raj/pictures /registration', '/usr/lib/python2.6',....]
Any thoughts would be appreciated.
Is it in the pythonpath for the webserver? All those '/opt' paths are typically not in the standard python path, so something is adding those for you I would guess. Are you sure it also gets added for the webserver process, or is PYTHONPATH set in some shell configfile somewhere for your user only?
There is a PythonPath directive when using mod_python, is there something similar for mod_wsgi?
This is almost certainly a case of the path not being the same for the webserver as it is for you, so I would focus my search in those areas.