python virtualenv(wrapper) + uwsgi + nginx (YET AG

2019-09-05 11:29发布

问题:

Ok, I know there are loads of virtualenv + uwsgi + nginx articles out there, I've read about 50 of them (I have not fully read the uWSGI documentation).

My question:

Why do none of these options actually activate the virtualenv I am asking it to do?

[uwsgi]
home = <path to python3 venv>
venv = <path to python3 venv>
virtualenv = <path to python3 venv>

However I try, I can't start uwsgi(installed and working) from the default python2.7, and have it read the uwsgi.ini, activate the virtualenv, and fire up my django-project. uwsgi is also installed on the virtualenv.

All other stuff is in place (users, groups and permissions), and working.

FAIL: Starting with no virtualenv active:

$> uwsgi --ini uwsgi.ini
[uWSGI] getting INI configuration from uwsgi.ini
*** Starting uWSGI 2.0.9 (64bit) on [Fri Feb 13 14:48:03 2015] ***
compiled with version: 4.8.2 on 20 January 2015 14:01:30
os: Linux-3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014
nodename: intergate.io
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /www/django/intergate_io
writing pidfile to /www/django/intergate_io/run/project-master.pid
detected binary path: /usr/local/bin/uwsgi
chdir() to /www/django/intergate_io
your processes number limit is 3750
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: enabled
uwsgi socket 0 bound to UNIX address /www/django/intergate_io/run/socket.sock fd 3
Python version: 2.7.6 (default, Mar 22 2014, 23:03:41)  [GCC 4.8.2]
Set PythonHome to /opt/vEnvs3/django/
ImportError: No module named site

Sucess: Activating virtualenv, and starting:

$> workon django
(django) $> uwsgi --ini uwsgi.ini
*** Starting uWSGI 2.0.9 (64bit) on [Fri Feb 13 14:49:42 2015] ***
compiled with version: 4.8.2 on 13 February 2015 06:07:54
os: Linux-3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014
nodename: intergate.io
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /www/django/intergate_io
writing pidfile to /www/django/intergate_io/run/project-master.pid
detected binary path: /opt/vEnvs3/django/bin/uwsgi
chdir() to /www/django/intergate_io
your processes number limit is 3750
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: enabled
uwsgi socket 0 bound to UNIX address /www/django/intergate_io/run/socket.sock fd 3
Python version: 3.4.0 (default, Apr 11 2014, 13:08:40)  [GCC 4.8.2]
Set PythonHome to /opt/vEnvs3/django/
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0xe7fc00
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 218280 bytes (213 KB) for 2 cores
*** Operational MODE: preforking ***
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0xe7fc00 pid: 2682 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 2682)
spawned uWSGI worker 1 (pid: 2683, cores: 1)
spawned uWSGI worker 2 (pid: 2684, cores: 1)

回答1:

In the first case you seem to be launching some kind of global (maybe one installed with sudo pip) uwsgi, as indicated by output:

detected binary path: /usr/local/bin/uwsgi

It may be missing python3 plugin to properly switch environments, and in general I found it is always simpler to use uwsgi from virtualenv - it just works more often. Really, don't bother trying to make system-wide work, use your own. You will need to put a full path in one more config, but that's hardly a problem. Just launch /path/to/your/venv/bin/uwsgi instead of just uwsgi.