I am trying to follow the steps in this guide: http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html
Before I even get to the nginx part I am trying to make sure that uWSGI works correctly
my folder structure is srv/www/domain/projectdatabank/
the project databank folder contains my manage.py file
my wsgi.py file looks like this:
import os
import sys
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
do you need to see my settings.py?
i get the following error when i point myself to the browser:
-- no python application found, check your startup logs for errors ---
[pid: 10165|app: -1|req: -1/1] 66.56.35.151 () {38 vars in 681 bytes} [Tue Jul 9 18:19:46 2013] GET /admin/ => generated 21 bytes in 0 msecs (HTTP/1.1 500) 1 headers in 57 bytes (0 switches on core 0)
--- no python application found, check your startup logs for errors ---
[pid: 10165|app: -1|req: -1/2] 66.56.35.151 () {36 vars in 638 bytes} [Tue Jul 9 18:19:49 2013] GET / => generated 21 bytes in 0 msecs (HTTP/1.1 500) 1 headers in 57 bytes (0 switches on core 0)
Now when I check my uWGI log it is just the same as above.
I have solved this
in my original command line did not include full path to the wsgi.py file to run uWSGI
uwsgi --http :8000 --chdir /srv/www/databankinfo.com/projectdatabank/ --wsgi-file wsgi.py
to this
uwsgi --http :8000 --chdir /srv/www/databankinfo.com/projectdatabank/ --wsgi-file full/path/wsgi.py
and it worked
For others debugging this same error, there is another possibility: an exception is being thrown by your uwsgi.py. To test this, open a django shell in your app directly with python manage.py shell and import your uwsgi.py (use the same path as in your uwsgi.ini).
Check out my blog post on deploying Django behind uwsgi http://blog.johannesklug.de/2012/11/27/deploying-django-behind-nginx-with-uwsgi-and-virtualenv/. I created an ini-File to setup uwsgi, which points to the app callable with the parameter module=project.wsgi:application.
The whole file reads something like this:
(env)[project#host ~]$ cat uwsgi.ini
[uwsgi]
# path to where you put your project code
chdir=/home/project/project
# python path to the wsgi module, check if you have one
module=project.wsgi:application
# this switch tells uwsgi to spawn a master process,
# that will dynamically spawn new child processes for
# server requests
master=True
# uwsgi stores the pid of your master process here
pidfile=/home/project/master.pid
vacuum=True
# path to your virtual environment
home=/home/project/env/
# path to log file
daemonize=/home/project/log
# this is where you need to point nginx to,
# if you chose to put this in project home make
# sure the home dir is readable and executable by
# nginx
socket=/tmp/uwsgi.sock
### SEE UPDATE NOTICE FOR THIS ONE
env = DJANGO_SETTINGS_MODULE=project.settings
Please note that I'm using virtualenv.
You might also be missing the lines
import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project.settings")
in your wsgi.py
Check if u deleted any init.py file from the Djano apps. As django uses them to know which folders are apps, so they are kind of important.
I got this error because my /etc/uwsgi/vassals/ ini file for the site I was running had the word "module" misspelled as "modeule". Check that file carefully if you see htis ereror.
In uwsgi.ini
Make sure you have set the right module.
[uwsgi]
module = yourapp.wsgi:application
...
Related
Hello I have a django app. My whole system configuration is the following: python 3, django 1.11, eventlet 0.21.0.
1) Nginx as an upstream server:
upstream proj_server {
server unix:///tmp/proj1.sock fail_timeout=0;
server unix:///tmp/proj2.sock fail_timeout=0;
}
2) Supervisor that controls workers. There is a gunicorn worker:
[program:proj]
command=/home/vagrant/.virtualenvs/proj/bin/gunicorn -c /vagrant/proj/proj/proj/deploy/gunicorn.small.conf.py proj.wsgi:application
directory=/vagrant/proj/proj/proj/deploy
user=www-data
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/proj.log
3) This is a gunicorn.small.conf content:
bind = ["unix:///tmp/proj1.sock", "unix:///tmp/proj2.sock"]
pythonpath = "/vagrant/proj/proj/proj/deploy"
workers = 2
worker_class = "eventlet"
worker_connections = 10
timeout = 60
graceful_timeout = 60
4) And this is proj.wsgi content:
"""
WSGI config for proj project.
This module contains the WSGI application used by Django's development server
and any production WSGI deployments. It should expose a module-level variable
named ``application``. Django's ``runserver`` and ``runfcgi`` commands discover
this application via the ``WSGI_APPLICATION`` setting.
Usually you will have the standard Django WSGI application here, but it also
might make sense to replace the whole Django WSGI application with a custom one
that later delegates to the Django one. For example, you could introduce WSGI
middleware here, or combine a Django application with an application of another
framework.
"""
import eventlet
eventlet.monkey_patch()
from eventlet import wsgi
import django.core.handlers.wsgi
import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "proj.settings")
# This application object is used by any WSGI server configured to use this
# file. This includes Django's development server, if the WSGI_APPLICATION
# setting points here.
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
# Apply WSGI middleware here.
# from helloworld.wsgi import HelloWorldApplication
# application = HelloWorldApplication(application)
So, as you can see there is a chain: nginx as an upstream server calls one of the gunicorn eventlet workers using two sockets proj1.sock or proj2.sock.
Note that according with the eventlet documentation I try to use eventlet.monkey_patch() as early as possible. The most appropriate place for that is proj.wsgi that is called by gunicorn in the first place.
However it seems that library isn't monkey patched.
To check this I added to the proj/proj/proj/__init__.py (the first module that called by the django application) the following code:
import eventlet
import os
print("monkey patched os is: " + str(eventlet.patcher.is_monkey_patched('os')))
print("monkey patched select is: " + str(eventlet.patcher.is_monkey_patched('select')))
print("monkey patched socket is: " + str(eventlet.patcher.is_monkey_patched('socket')))
print("monkey patched time is: " + str(eventlet.patcher.is_monkey_patched('time')))
print("monkey patched subprocess is: " + str(eventlet.patcher.is_monkey_patched('subprocess')))
then i issued **./manage.py check** and got that answer:
monkey patched os is: false
monkey patched select is: false
monkey patched socket is: false
monkey patched time is: false
monkey patched subprocess is: false
What am I doing wrong?
What if you change proj.wsgi file content to one line raise Exception? That should eliminate eventlet from suspects.
I'm not good with Django, here's a pure speculation:
based on name, proj.wsgi is executed when WSGI server is about to start
manage.py check doesn't seem to be related to remote network service (WSGI), seems to be a general management command, so it shouldn't execute WSGI related code
One possible solution, taken from your question text:
proj/proj/proj/init.py (the first module that called by the django application
Try to put monkey_patch call in there.
P.S.: you don't need supervisor for gunicorn, its master process (arbiter) is designed to run forever in spite of problems with workers.
I have Django setup in NGINX + uWSGI. I'm able to get it running fine under my current logged in user (with help from a question I asked few days back) but now I want to run uwsgi --ini uwsgi.ini as a limited-access user.
Here is what I've done so far:
1. Created a user djangouser without login access and without a home directory.
2. Added user nginx into group djangouser
3. Placed my django files into /mnt/django directory and changed file permissions of django to drwxrwx--- djangouser djangouser (recursive)
4. Changed the conf files to match the file locations
uwsgi.ini file
[uwsgi]
chdir=/mnt/django/project/awssite
module=awssite.wsgi
home=/mnt/django/project
master=true
processes=2
uid=djangouser
gid=djangouser
socket=/mnt/django/djangosocket/awssite.socket
chmod-socket
vacuum=true
When I try to run uwsgi --ini uwsgi.ini, this is the error I get
[uWSGI] getting INI configuration from uwsgi.ini
*** Starting uWSGI 2.0.12 (64bit) on [Thu Feb 18 00:18:25 2016] ***
compiled with version: 4.8.3 20140911 (Red Hat 4.8.3-9) on 01 February 2016 04:17:11
os: Linux-4.1.13-19.31.amzn1.x86_64 #1 SMP Wed Jan 20 00:25:47 UTC 2016
nodename: ip-10-200-1-89
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/ec2-user
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
chdir() to /mnt/django/project/awssite
chdir(): Permission denied [core/uwsgi.c line 2586]
chdir(): Permission denied [core/uwsgi.c line 1608]
Note: When I added my logged in user to djangouser group, uwsgi --ini uwsgi.ini ran fine and I was able to load the django pages.
I'm not sure where else to add permissions to allow this to work. Adding sudo chown-socket=djangouser:djangouser in uwsgi.ini didn't work either.
I appreciate the help :)
If you want to run uWSGI as particular user, there are only 2 options:
run uWSGI server directly from this user
run uWSGI as root and add uid and gid options.
You can create a user and set the uid/gid properties in your uwsgi ini file.
[uwsgi]
...
uid=myuser
gid=mygroup
I tested this with uwsgi version 2.0.12-debian and it worked for a simple cgi app using a python3 virtualenv.
http://uwsgi-docs.readthedocs.io/en/latest/Options.html#uid
I have the following config file for Upstart, and it starts the Flask server fine, but whenever there is an exception in the app the log file doesn't have the exception information.
start on [2345]
stop on [06]
respawn
script
cd /var/www/binary-fission/server
export BF_CONFIG=config/staging.py
exec uwsgi --http 0.0.0.0:5000 --wsgi-file server.py --callable app --master --threads 2 --processes 4 --logto /var/log/binary-fission/server.log
end script
However, if I run the same uwsgi command manually without Upstart, the exception is logged.
How do I make upstart+uwgi log the exception from a Flask application?
It turned out that turning on the "PROPAGATE_EXCEPTIONS" option in the flask configuration file (config/staging.py) fixed the issue. This is because in that configuration file, "DEBUG" is turned off which turns "PROPAGATE_EXCEPTIONS" off at the same time.
When I ran uwsgi command manually, I didn't specify the configuration file and my Flask app fell back to the default configuration with "DEBUG" on.
I am trying to deploy a Django app using nginx + uwsgi.
I created a virtual environment (virtualenv), and installed both uwsgi and Django inside the virtual env (i.e.local to the virtual environment). I have no global Django and uwsgi. When I run the uwsgi --ini project.ini, I am having an 'ImportError: No module named django.core.wsgi' exception:
from django.core.wsgi import get_wsgi_application
ImportError: No module named django.core.wsgi
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 ***
spawned uWSGI master process (pid: 5987)
spawned uWSGI worker 1 (pid: 5988, cores: 1)
spawned uWSGI worker 2 (pid: 5989, cores: 1)
spawned uWSGI worker 3 (pid: 5990, cores: 1)
spawned uWSGI worker 4 (pid: 5991, cores: 1)
Based on my search, it's recommended to put env and pythonpath variables in the ini if you are using Django1.5 or lower. However, I am using Django 1.7, so I did not place them anymore. Here's my project.ini:
#project.ini file
[uwsgi]
# Django-related settings
# the base directory (full path)
chdir = /root/virtualenv/project
# Django wsgi file
module = project.wsgi:application
# the virtualenv (full path)
home = /root/virtualenv
# process-related settings
# master
master = true
# maximum number of worker processes
processes = 4
# the socket (use the full path to be safe
socket = /root/virtualenv/project/project.sock
# ... with appropriate permissions - may be needed
chmod-socket = 666
chown-socket = root:root
# clear environment on exit
vacuum = true
# other config options
uid = root
gid = root
processes = 4
daemonize = /var/log/uwsgi/project.log
no-site = True
How will i fix this? I'm quite stuck on this for a day already.
Any ideas are greatly appreciated.
Thanks in advance!
your module is pointed to your project, shouldn't it be pointed to your projects main app that way it can find the wsgi file?
so on my INI file looks like this.
In my particular case I'm using a virtual environment, django 1.7 and uwsgi.
vhost = true
plugins = python
socket = /tmp/noobmusic.sock
master = true
enable-threads = true
processes = 2
wsgi-file = /home/myname/webapps/music/music/music/wsgi.py
virtualenv = /home/myname/webapps/music/musicenv/
chdir = /home/myname/webapps/music/music/
this is the only site I've ever setup uwsgi as I typically use mod-wsgi and unfortunately do not remember all the steps.
I had similar issue. Solved it -after many hours- by making sure that uwsgi is installed using same python version (2 / 3) as the python version of your virtualenv. Otherwise it will not use your virtualenv and thus start throwing 'can not find module xyz' kind of errors. To install uwsgi under python3 you have to use pip3 (which in turn might need to be installed with something like 'apt-get install python-pip3'). When calling uwsgi on cli or via .ini file you need to reference your virtualenv mentioning the full path (which ends one folderlevel above the folder in which the /bin/ is; so /example/myvenv/bin/activate means the full path is /example/myvenv.
I made the uwsgi install global so outside of my virtualenv. I suppose above applies/would work as well when installing uwsgi within the virtualenv, but have not tried (yet).
Keep the system-wide uwsgi the same version as your virtual environment python.
In my environment, my virtual environment is python3.7, but the system default python is python3.6.
After I uninstall uWSGI, and re-install the system-wide uWSGI with python3.7, the problem has been resolved.
sudo pip uninstall uwsgi
sudo -H python3.7 -m pip install uwsgi
I can't see any problem in your configuration (though I'm not very good at these topics). I can try to advice some steps to localize the problem.
Test uwsgi without using virtualenv. Note that the virtual directory is just a directory, so add it to your PYTHONPATH and run uwsgi.
Before that you can try
python -c 'import django.core.wsgi'
If that works, then the problem is in uwsgi virtualenv configuration.
Test virtualenv. Run it and check that the module can be imported.
If that works, then the problem is in uwsgi. Go to the previous case.
Setting up my first app. I started on the django development server, and am now moving things to an apache setup so that I can code in my target prod environment. I've gotten mod_wsgi set up successfully and got a successful "Hello World!". Now I'm having issues actually getting my app to respond in apache the way it did in the django dev server.
Here's my directory structure:
/var/www/www.example.com/ [site directory]
Example [my app]
wsgi.py
settings.py
users [another django module i wrote]
trips [yet another django module i wrote]
Now, in my virtual host file, I have the following line:
WSGIScriptAlias / /var/www/www.example.com/Example/wsgi.py
And in my wsgi.py file, I have the following lines:
sys.path.append('/var/www/www.example.com/Example')
sys.path.append('/var/www/www.example.com/trips')
sys.path.append('/var/www/www.example.com/users')
Yet, here's the error I'm getting:
[Sun Jan 06 21:37:46 2013] [error] [client 127.0.0.1] ImportError: No module named trips
What do I need to do to get django and mod_wsgi to recognize my trips and users apps?
Thanks!
don't add every module to sys.path.
Instead you should add /var/www/www.example.com to sys.path.