django working via shell but via browser gets 504

Question

I am working on a Django system with a Mongo backend, my first time experimenting with this setup. It has a fairly standard nginx-hands-off-to-Apache-for-python server setup. This all seems to work for a more standard Django-MySQL app on the same server.

For my Django-Mongo app, when I use 'python manage.py shell', I get:

from django.test.client import Client
client = Client()
response = client.get('/')
response.status_code
200
response.content
'<html>\n  <head>\n    <link href="/static/blog.css" rel="stylesheet" type="text/css">\n    <title>Worldmaker</title>\n  </head>\n  <body>\n      <ul>\n        <li><a href="sourcedoc/create/">New Sourcedoc</a></li>\n        <li><a href="sourcedoc/list/">All Sourcedocs</a></li>\n        <li><a href="noun/create/">New Noun</a></li>\n        <li><a href="noun/list/">All Nouns</a></li>\n      </ul>\n      <h1>Worldmaker</h1>\n    \n\n  </body>\n</html>\n\n'

However, when I browse to http://www.mydomain.com/gogoworld/, I get an nginx 504 page:

504 Gateway Time-out nginx/1.4.1

My /etc/nginx/sites-enabled/vhost includes this:

  location /gogoworld/ {
    proxy_pass http://127.0.0.1:84;
    include /etc/nginx/proxy.conf;
  }

My /etc/apache2/httpd.conf includes this:

<Directory "/home/rosshartshorn/htdocs/gogoworld">
WSGIScriptAlias /gogoworld /home/rosshartshorn/htdocs/gogoworld/wsgi.py

WSGIPythonPath /home/rosshartshorn/htdocs/ordinarymysqlapp:/home/rosshartshorn/htdocs/worldmaker:/home/rosshartshorn/htdocs/gogoworld

My urls.py

from django.conf.urls import patterns, include, url

from sourcedocs import views

urlpatterns = patterns('',
    url(r'^$', views.index),
)

My confusion is to what the difference is between the use of django.text.client, and pinging the site with my web browser. I had thought it was the same thing, but since one returns a response and the other doesn't, I am obviously incorrect. Is the difference only at the apache and/or nginx level, or are there parts of the django machinery that are different as well? Any ideas on where to look to see why this works in the django shell but not via the browser?

Edit: here's what's in my sites-available/rosshartshorn:

Listen 84

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>
<VirtualHost *:84>
  ServerName     www.rosshartshorn.net
  ServerAlias rosshartshorn.net
  DocumentRoot /home/rosshartshorn/htdocs
  <Directory /home/rosshartshorn/htdocs>
    AllowOverride All
    allow from all
  </Directory>
</VirtualHost>

Testing with `django.test.client` is similar as testing with Django built-in webserver (by `manage.py runserver`). At the moment you are using a "real world" stack nginx-apache-django, so I guess the problem lies somewhere in the configuration between nginx and apache. Could you describe your stack in more detail? Something like: browser => nginx => Apache => Django? — Hieu Nguyen, Jul 22 '13 at 19:47
Yes, nginx hands off to Apache for the subfolder this app is in (and also for a Django-mysql app, which works, so I think this is correct). Then Apache is supposed to hand off to Django, and again it does for the older app. Nginx has port 80 and sends to port 84, which is for Apache. I believe the older app was written under Django 1.3, and the newer one is written under Django 1.5, so their directory structures are a little different due to changes in Django, but it seems like we're not even getting to that point. — rossdavidh, Jul 22 '13 at 22:43
Since 504 means that your request never reach the backend server, it makes sense to test django and apache alone first. Could you try to reconfig Apache a bit (if needed) to listen to port 84 and try `yourdomain.com:84` first? — Hieu Nguyen, Jul 23 '13 at 01:01
Thanks for your help, Hieu, these are great suggestions. When I browse to port 84 directly, I don't get the 504 page but it does just spin forever. So it would appear that nginx is not part of the problem, it's just reporting on the fact that nothing is coming back from Apache. Thus, I guess this means it's not django, and it's not nginx, so it must be Apache? — rossdavidh, Jul 23 '13 at 14:41
Yeah apache configuration is off or something like that, I'm not very good with config apache and django (all my sites are django+nginx) so I don't know much the detail. — Hieu Nguyen, Jul 23 '13 at 14:44
I wonder if trying to have nginx and Apache both in the mix is just giving me more things to get wrong. I take it you get good enough performance with just nginx with Django? — rossdavidh, Jul 23 '13 at 14:57
Of course, more things more human errors. Remember that `/var/error_log` will be your friend. My stack is usually nginx + gunicorn + django and I'm happy with it. It seems to me that stack Apache + nginx + something is quite popular at the moment but it's for really big sites that need to scale badly. — Hieu Nguyen, Jul 23 '13 at 15:10

score 0 · Answer 1 · answered Jul 24 '13 at 17:13

Many thanks to Hieu Nguyen for his comments above, which helped me find my way to debug this. Lots of use of /var/log/apache2/error.log to see what was happening/not happening, along with "import sys print >> sys.stderr, [some debug statement]"

It turns out the problem was in my /etc/apache2/httpd.conf, which now looks more like this:

WSGIScriptAlias /secretoktobermoneymade /home/rosshartshorn/htdocs/ordinarymysqlapp/wsgi.py
WSGIScriptAlias /gogoworld /home/rosshartshorn/htdocs/gogoworld/gogoworld/wsgi.py

WSGIPythonPath /home/rosshartshorn/htdocs/gogoworld/:/home/rosshartshorn/htdocs/gogoworld/gogoworld:/home/rosshartshorn/htdocs/ordinarymysqlapp

Previously, I had a combination of not having the location of the gogoworld/wsgi.py being on the python path, and then also a problem of gogoworld/wsgi.py finding the settings.py of ordinarymysqlapp first and running that (this is why I switched the order so that gogoworld occurs in WSGIPythonPath first). I believe that there is probably a better way of setting things up when you have multiple django apps, but this setup does seem to be working for both the new and the old app.

Long story short: multiple django apps require more knowledge of Apache than one, and if you aren't an Apache guru then you will have to spend some time fiddling with it to get the right wsgi.py executing, and the right settings!

This thread was also useful in setting things up for two different django projects: http://stackoverflow.com/questions/9581197/two-django-projects-running-simultaneously-and-mod-wsgi-acting-werid — rossdavidh, Jul 30 '13 at 15:12

django working via shell but via browser gets 504

1 Answers1