uWSGI Emperor模式无法在Virtualenv外部运行

Question

I'm trying to run a Django application through uWSGI by using the Emperor Mode and vessels, the vessel points correctly to the ini file and the ini file defines home as /home/ user /.virtualenvs/myvirtualenv, however this doesn't work (the log says that the connection was prematurely closed). But if I run the same command while in the virtualenv, it all works perfectly, so my guess is that uWSGI is ignoring the home option. This is, however, not useful since I need to run a couple different apps each using their own virtualenv (hence why I need emperor mode).

This is the mentioned vessel ini:

# mysite_uwsgi.ini file
[uwsgi]

#virtualenv            = /home/ariel/.virtualenvs/django-ag-panel/
# Django-related settings
# the base directory (full path)
chdir           = /home/ariel/Desarrollo/Django/django-ag-panel/ag_panel
# Django's wsgi file
module          = ag_panel.wsgi
# the virtualenv (full path)
home            = /home/ariel/.virtualenvs/django-ag-panel/

And this is the command I use to run the emperor (I'm using the same user as the one that hosts the app to avoid yet more file permission issues):

uwsgi --emperor /etc/uwsgi.d/vassals

And my vassal is in fact there:

[ariel@e11 ~]$ ls -l /etc/uwsgi.d/vassals/
total 0
lrwxrwxrwx. 1 root root 73 feb  7 21:37 ag_panel_uwsgi.ini -> /home/ariel/Desarrollo/Django/django-ag-panel/ag_panel/ag_panel_uwsgi.ini

As I said, everything works correctly if I run the uWSGI command while in the virtualenv:

workon django-ag-panel
uwsgi --emperor /etc/uwsgi.d/vassals

What am I doing wrong?

Answer 1

I was getting the "prematurely closed connection" issue because I was trying to communicate to the app through NGINX and uWSGI. The real issue was that the vessel was not being loaded correctly, and by running it manually (outside of the virtualenv) I found out that the issue was a 'site' module not found error, this was, in turn, caused because the globally installed (using yum, by the way), distributor-provided uWSGI package didn't have python support built in and the instance couldn't start correctly. Which takes us to the following…

I think that probably many people has tried to configure uWSGI + NGINX on Linux by following these tutorials:

1. http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html
2. https://www.digitalocean.com/community/tutorials/how-to-deploy-python-wsgi-applications-using-uwsgi-web-server-with-nginx
3. https://www.digitalocean.com/community/tutorials/how-to-serve-django-applications-with-uwsgi-and-nginx-on-ubuntu-14-04

And probably some other ones; what they don't point out is that the uWSGI version you get from the pip command and from the package distributor are somewhat different, as this uwsgi quickstart guide points out, the distributor may compile uWSGI in a "modular" fashion:

One thing you may want to take into account when testing this quickstart with distro-supplied packages, is that very probably your distribution has built uWSGI in modular way (every feature is a different plugin that must be loaded). To complete this quickstart, you have to prepend --plugin python,http to the first series of examples, and --plugin python when the HTTP router is removed…

Whereas the package you get with pip comes with python support right out of the box (at least in my case, on Fedora Linux 23). What is more, since the package manager and pip are independent you can have both the distributor and the pip version simultaneously installed, and if this is already problematic, imagine now a third, local version of the package in your virtualenv. The steps I followed were as follows:

1. Remove all and every version of uwsgi you have installed in your system (or at least try to clean up your execution path from either the pip or the distributor-provided package)
2. Install only the version of the package you need (or leave only one, in case you didn't remove everything in the previous step).

3. In case you choose the modular, distributor-provided version:

   Make sure you also install the uwsgi-plugin-python.x86_64 and uwsgi-plugin-python3.x86_64 packages, along with these ones: uwsgi-router-http.x86_64 , uwsgi-plugin-common.x86_64 , and something else you might need. Then, run your uwsgi instance with the --plugin option to enable either python or python3 support, before any of your other options. The 'site' module not found error should be gone now. You can also use that option in the ini file (like plugin = python3 ) in case you run using config files or vassals.

4. In case you choose the pip version: Just use it like you would normally do.

In all cases, make sure which version you are calling and you should be fine.