Reputation: 2770
I have the following vassal configuration in /etc/uwsgi/vassals/gsd.ini
:
[uwsgi]
plugins = python
env = DJANGO_SETTINGS_MODULE=%n.settings
virtualenv = /home/toogy/.pyenv/versions/%n
chdir = /home/webapps/%n
module = %n.wsgi:application
master = true
vacuum = true
pidfile = /tmp/uwsgi-%n.pid
socket = /tmp/uwsgi-%n.sock
daemonize = /var/log/uwsgi/%n.log
chmod-socket = 666
uid = toogy
gid = toogy
Here is the uwsgi log I get
Tue Feb 7 10:49:12 2017 - received message 1 from emperor
...gracefully killing workers...
Gracefully killing worker 1 (pid: 31406)...
worker 1 buried after 1 seconds
binary reloading uWSGI...
chdir() to /etc/uwsgi/vassals
closing all non-uwsgi socket fds > 2 (max_fd = 1024)...
found fd 3 mapped to socket 0 (/tmp/uwsgi-gsd.sock)
running /usr/bin/uwsgi
*** has_emperor mode detected (fd: 7) ***
[uWSGI] getting INI configuration from gsd.ini
*** Starting uWSGI 2.0.14 (64bit) on [Tue Feb 7 10:49:13 2017] ***
compiled with version: 6.3.1 20170109 on 18 January 2017 00:35:47
os: Linux-3.14.32-xxxx-grs-ipv6-64 #7 SMP Wed Jan 27 18:05:09 CET 2016
nodename: renard
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/bin/uwsgi
chdir() to /home/webapps/gsd
your processes number limit is 15700
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 inherited UNIX address /tmp/uwsgi-gsd.sock fd 3
Python version: 3.6.0 (default, Jan 16 2017, 12:12:55) [GCC 6.3.1 20170109]
PEP 405 virtualenv detected: /home/toogy/.pyenv/versions/gsd
Set PythonHome to /home/toogy/.pyenv/versions/gsd
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x39d21f0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145536 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
added /home/webapps/gsd/ to pythonpath.
Traceback (most recent call last):
File "/home/webapps/gsd/gsd/wsgi.py", line 12, in <module>
from django.core.wsgi import get_wsgi_application
ModuleNotFoundError: No module named 'django'
unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
gracefully (RE)spawned uWSGI master process (pid: 27844)
spawned uWSGI worker 1 (pid: 32312, cores: 1)
It cannot find django
and I have no idea why because uwsgi
seems to detect the python environment (in which django
is installed).
Also, it says Python version: 3.6.0
while my virtualenv Python version is 3.5.2. I don't know if this is supposed to happen. The system Python version is 3.6.0.
I am using the last versions of the uwsgi
and uwsgi-plugins-python
Arch Linux official packages.
Upvotes: 13
Views: 14938
Reputation: 11
When I execute:
uwsgi --socket client_book.sock --module myproject.wsgi --chmod-socket=666
in the directory ~/
, and I would get the following error:
ModuleNotFoundError: No module named 'myproject.wsgi'
The solution was to run the command one layer deeper in the directory ~/myproject
This way, uwsgi
was able to find myproject.wsgi
.
This was what fixed it for me.
Upvotes: 1
Reputation: 2770
The problem was that the system-wide python version linked to uwsgi needs to be the same as the one of the virtualenv, which, I think, is a very stupid thing.
EDIT April 2021: I now recommend using gunicorn, which does not have this problem
Upvotes: 35
Reputation: 76
In my case it was using the system wide uwsgi, I'm working using a virtualenv so if I execute
$ which uwsgi
I got /usr/local/python3.6/bin/uwsgi
As Valentin Iovene suggests you need to use the uwsgi from your virtual environment
My directories structure is something like this:
~/Env
--/app
--/bin
----/....
----/uwsgi <-- This should be the good one
----/...
--/include
--/lib
(The app directory is where my django app resides)
In my case uwsgi file hasn't execution permissions so I only executed:
$ chmod +x ~/Env/bin/uwsgi
Finally under my app directory I executed the uwsgi command as follows:
../bin/uwsgi --http :8000 --module app.wsgi
Now I can see my app working now :)
I'm following this guide: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html
Next steps are configuring nginx and https...
I know it's a late response but hope this helps and shared what worked for me.
Upvotes: 3
Reputation: 221
I also found some possible pitfalls I want to share:
virtualenv
(which is the same as venv
, pyhome
and home
) is set to that directory, that contains the bin
, include
, lib
, ... directoriesuid
) can read the files in your project and the libs in virtual environment (this ends in a ModuleNotFoundError
instead of a permission error)need-app
to exit on failures (this helps for debugging and should be default imho)strict
to avoid typos in config (this should also be default...)if your test.py
runs, try to import modules of your project and your virtual environment, to test if that works. It also helps to add a
import sys
print(sys.path)
You can also copy the printed sys.path
, open a python shell and set sys.path
to the same value and try to import the desired wsgi module.
Upvotes: 3
Reputation: 110
look at this at gsd.ini
:
virtualenv = /home/toogy/.pyenv/versions/%n
have you install django
under this virtualenv?
Upvotes: 1