Nginx & uWSGI: ImportError: No module named site

djangonginxuwsgi

I'm receiving an error: ImportError: No module named site according to my uWSGI log.

test_proj.ini:

[uwsgi]
chdir = /home/%n/app
module = %n.wsgi
home = /home/%n/app/venv
master = true
processes = 10
chmod-socket = 664
socket = /home/%n/uwsgi/socket
daemonize = /home/%n/uwsgi/log
pidfile = /home/%n/uwsgi/pid

nginx:

server {
        listen 8888;
        server_name 192.168.88.187;

        # Set up django static file serving
        location /static {
                alias /home/test_proj/app/static/;
        }

        # pass all non-static request to uWSGI
        location / {
                uwsgi_pass unix:///home/test_proj/uwsgi/socket;
                include uwsgi_params;
        }
}

pip freeze:

Django==1.7.1
django-braces==1.4.0
django-cors-headers==0.13
django-dynamic-settings==1.1.0
django-oauth-toolkit==0.7.2
django-uuidfield==0.5.0
djangorestframework==3.0.0
oauthlib==0.7.2
psycopg2==2.5.4
six==1.8.0

I also have uWSGI installed globally. Am I missing something in the ini file or is it because of my nginx settings? I've tried different combinations of the ini file.

I've also tried adding no-site = true inside the ini but I learned that it shouldn't be added to the ini file even though it removes the error and produces a different error.

I also followed this tutorial but still no luck.

Thanks.

Best Answer

The reason why it wasn't working is because I installed uwsgi using the regular pip command. Since I have both Python 2 & 3 in the machine, I need to install uwsgi using pip3.

The command I ran: pip3 install uwsgi

Related Solutions

Python/Django/WSGI/Apache – “ImportError: No module named site”

Your mod_wsgi was compiled for Python 2.7. You cannot then try and point it at a Python 2.5 virtual environment.

Also, the setting:

WSGIPythonHome /home/rory/tix/virtualenv2.5/lib/python2.5/

is pointing at the wrong thing even if it was a Python 2.7 virtual environment.

The settings:

UnSetEnv PYTHONSTARTUP
SetEnv PYTHONPATH /home/rory/tix/virtualenv2.5/lib/python2.5/

will not do anything either and don't know where you got the idea you could do that.

FWIW, the mod_wsgi documentation on virtual environments can be found at:

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

This isn't going to help you though because you seem to have a more basic problem with your mod_wsgi and Python installations to begin with. The issue potentially being a variant of:

https://modwsgi.readthedocs.io/en/develop/user-guides/installation-issues.html#multiple-python-versions

Where did you get the mod_wsgi.so you are using?

Where is the Python 2.7 installed?

What other Python versions do you have installed and where?

Nginx – need Nginx and something like Gunicorn

Overly simplified: You need something that executes Python but Python isn't the best at handling all types of requests.

[disclaimer: I'm a Gunicorn developer]

Less simplified: Regardless of what app server you use (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) any sort of non-trivial deployment will have something upstream that will handle the requests that your Django app should not be handling. Trivial examples of such requests are serving static assets (images/css/js).

This results in two first tiers of the classic "three tier architecture". Ie, the webserver (Nginx in your case) will handle many requests for images and static resources. Requests that need to be dynamically generated will then be passed on to the application server (Gunicorn in your example). (As an aside, the third of the three tiers is the database)

Historically speaking, each of these tiers would be hosted on separate machines (and there would most likely be multiple machines in the first two tiers, ie: 5 web servers dispatch requests to two app servers which in turn query a single database).

In the modern era we now have applications of all shapes and sizes. Not every weekend project or small business site actually needs the horsepower of multiple machines and will run quite happily on a single box. This has spawned new entries into the array of hosting solutions. Some solutions will marry the app server to the web server (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, etc). And its not at all uncommon to host the database on the same machine as one of these web/app server combinations.

Now in the case of Gunicorn, we made a specific decision (copying from Ruby's Unicorn) to keep things separate from Nginx while relying on Nginx's proxying behavior. Specifically, if we can assume that Gunicorn will never read connections directly from the internet, then we don't have to worry about clients that are slow. This means that the processing model for Gunicorn is embarrassingly simple.

The separation also allows Gunicorn to be written in pure Python which minimizes the cost of development while not significantly impacting performance. It also allows users the ability to use other proxies (assuming they buffer correctly).

As to your second question about what actually handles the HTTP request, the simple answer is Gunicorn. The complete answer is both Nginx and Gunicorn handle the request. Basically, Nginx will receive the request and if it's a dynamic request (generally based on URL patterns) then it will give that request to Gunicorn, which will process it, and then return a response to Nginx which then forwards the response back to the original client.

So in closing, yes. You need both Nginx and Gunicorn (or something similar) for a proper Django deployment. If you're specifically looking to host Django with Nginx, then I would investigate Gunicorn, mod_uwsgi, and maybe CherryPy as candidates for the Django side of things.

Best Answer

Related Solutions

Python/Django/WSGI/Apache – “ImportError: No module named site”

Nginx – need Nginx and something like Gunicorn

Related Topic