I try to configure uWsgi, Django ,Nginx with this document: http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html
Finish config the uwsgi.ini file, create a soft link at /etc/uwsgi/vassals.
Failed at the last step :Make uWSGI startup when the system boots.
When run this command:
sudo /usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data
I got this error:
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 3813
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)
bind(): Permission denied [core/socket.c line 227]
Tue May 27 05:29:26 2014 - [emperor] curse the uwsgi instance uwsgi.ini (pid: 1391)
Tue May 27 05:29:29 2014 - [emperor] removed uwsgi instance uwsgi.ini
If I run this command without sudo, everything is OK.
I've add user "kk" into group "www-data", and here is the uwsgi.ini
[uwsgi]
chdir = /home/kk/XXXXXXX
module = wsgi
home = /home/kk/XXXXXXX
master = true
processes = 10
socket = /home/kk/XXXXXXX/mysite.sock
chmod-socket = 666
vacuum = true
I guess maybe I made mistake on file permission. Does anybody have good idea?Thank you.
Update:
The official document is correct, I follow the steps to deploy the project in another new VPS, no error occurred.
I was having this problem. Running without setting the group and user ids solved the problem. I'll probably revisit this when I have more time to fix file permissions for the directory, but it works for the moment
/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals
EDIT I've had time to revisit this answer and I'd have to say that this is not good practice when running uwsgi in production.
The problem with the tutorial as written is that it assumes that www-data is a user and that the www-data user and group has access to all the files it needs on your server; in particular the socket file. Replace the appropriate arguments with your user and group and and you'll be good to go (and won't leave a gaping security hole on your server).
So, the correct command (if I was user ovangle in group ovangle would be):
/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid ovangle --gid ovangle
It would be better to create a user which has the specific permissions it needs to run the server successfully, but that's left as an exercise for the reader.
I don't know why the permissions don't work, but I ran into the same problem.
One quick way to fix this is to move the sockets to /tmp though! (Which is a fairly reasonable place to keep sockets anyway...)
so just update the uwsgi config with:
socket = /tmp/mysite.sock
and the nginx-config with:
upstream django {
server unix:///tmp/mysite.sock;
}
and it'll start working!
You did the permissions backwards.
uwsgi is running as www-data.
Your socket is in kk's home directly which is presumably owned by the kk user and the kk group.
You made it so that kk can access everything that www-data owns, not so www-data can access what kk owns.
You want to add the www-data to kk's group. This way www-data can reach the socket in kk's home.
usermod www-data -aG kk
Confirm with groups www-data and you should get back www-data : www-data kk showing that www-data is now in kk's primary group.
Now, provided kk's home folder permissions have at least '6' for the group permission www-data can read and write to the socket as necessary. E.g. chmod 660 /home/kk/XXXXXXX/mysite.sock.
This is how I got the socket to start securely. Are you running in a virtualenv? I got the same error message when I was sourced to the virtualenv with my app, since there's no sudo in the env. I had to deactivate the virtualenv then to install uwsgi globally. After installing uWSGI I needed to download the python3 plugin with sudo apt-get install uwsgi-plugin-python3, and add "plugins = python3" to my uWSGI ini file. After all of that I was able to start uWSGI with sudo/root eq. sudo uwsgi --ini mysite.ini.
As for security it's recommended to add these lines to the ini file:
uid = www-data
gid = www-data
chmod-socket = 644
# Plus here's the plugin I mentioned
plugins = python3
For these to be honored www-data has to own the parent directory where the mysite.sock file will be created, and the uwsgi command needs to be started with sudo. If either of those options are off then the socket gets created as the user who ran the uwsgi command.
If you are okay using a web port socket (like the first part of the demo) instead of unix sockets.. you could change this..
# uwsgi.ini
socket = :8001
and this..
# mysite_nginx.conf
upstream django {
# server unix:///home/teewuane/uwsgi-tutorial/mysite/mysite.sock; # for a file socket
server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}
and you will avoid the permission issues.
The cause of the issue you asking about is that uwsgi is trying to create a unix socket file to interact with a webserver via fastCGI protocol in directory you configured /home/kk/XXXXXXX/ You should set write permissions for the user you run uwsgi from to the directory /home/kk/XXXXXXX/
Ran into the exact same problem, after solving it by running with users and groups which have enough permission for the socket file, I realized this probably is a bug.
It's very confusing if you can actually run it in current user with uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data while once sudo is added you get bind(): Permission denied error.
The only explanation for this would be when you run it without sudo, somehow --uid www-data --gid www-data part DOES NOT work and you're actually running it with current user which have enough permision; and once sudo is added, --uid www-data --gid www-data part magically works again, which ends up with www-data not having enough permision to bind the socket file.
I also had this error. It turned that my folder had the wrong owner and group. Files inside were correct so I didn't catch it for a while.
Kind of resurrecting an old question, but I ran into this problem.
I found the solution. I had previously run uwsgi to test something as root. Later on I tried running it as www-data. Eventually I figured out that the stats server makes a socket file in /tmp/name.stats.sock this was owned by root and therefore would crash uwsgi. I just removed that and it works now!
I hope this helps anyone stumbling around with this.
来源：https://stackoverflow.com/questions/23886018/cant-run-uwsgi-as-root-bind-permission-denied