Well I am currently trying to get my django application served using nginx and uwsgi. I am currently using a virtual environment to which uwsgi is installed. However I am currently getting a 502 bad gateway error when attempting to access the page.
The Error I am experiencing.
2014/02/27 14:20:48 [crit] 29947#0: *20 connect() to unix:///tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 144.136.65.176, server: domainname.com.au, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "www.domainname.com.au"
This is my nginx.conf
# mysite_nginx.conf
# the upstream component nginx needs to connect to
upstream django {
server unix:///tmp/uwsgi.sock; # for a file socket
#server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}
# configuration of the server
server {
# the port your site will be served on
listen 80;
# the domain name it will serve for
server_name .domainname.com.au; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 75M; # adjust to taste
# Django media
location /media {
alias /home/deepc/media; # your Django project's media files - amend as required
}
location /static {
alias /home/deepc/static; # your Django project's static files - amend as required
}
# Finally, send all non-media requests to the Django server.
location / {
uwsgi_pass django;
include /home/deepc/.virtualenvs/dcwebproj/dcweb/uwsgi_params; # the uwsgi_params file you installed
}
}
Here is my uwsgi.ini file
[uwsgi]
socket=/tmp/uwsgi.sock
chmod-socket=644
uid = www-data
gid = www-data
chdir=/home/deepc/.virtualenvs/dcwebproj/dcweb
module=dcweb.wsgi:application
pidfile=/home/deepc/.virtualenvs/dcwebproj/dcweb.pid
vacuum=true
From what i have read on google its a permissions problem with the www-data group and /tmp/ directory. However I am new to this and have tried to changer the permission level of the folder to no avail. Could someone point me in the right direction? Is this a permissions problem.
Also is it ok practice to put the sock file in tmp directory?
Thanks
I think you just need to change your socket file to 666(664 is ok with www-data), or remove it and run uwsgi server again.
In my uwsgi.ini:
chmod-socket = 664
uid = www-data
gid = www-data
Wow, this problem takes me almost a whole day!
I use uwsgi 2.0.14, nginx 1.10.1, django 1.10
To sum up, the most important thing is to make sure both of below two users have rwx permission to socket file:
the user of nginx;
the user of uWSGI;
So, you can check them one by one.
First you can check if the web server nginx has permission by refreshing the url, say http://192.168.201.210:8024/morning/, without running uwsgi. If you see /var/log/nginx/error.log No such file or directory, like this:
2016/10/14 16:53:49 [crit] 17099#0: *19 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"
Just create a file named helloworld.sock, and refresh the url and check log file again, if you see Permission denied in log file, like this:
2016/10/14 17:00:45 [crit] 17099#0: *22 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"
It means web server nginx does not have all permission to read, write and execute. So you can grant permission to this file:
sudo chmod 0777 helloworld.sock
Then, refresh the url and check log file again, if you see Connection refused
in log file, like this:
2016/10/14 17:09:28 [error] 17099#0: *25 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"
This is a good sign, it means your web server nginx has the permission to use helloworld.sock file from now on.
Next to run uwsgi and check if the user of uwsgi has permission to use helloworld.sock. Firstly, remove the file helloworld.sock we have created before.
Run uwsgi: uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py
If you see bind(): Permission denied [core/socket.c line 230], it means uwsgi don't have permission to bind helloworld.sock. This is the problem of the directory test, the parent directory of helloworld.sock.
sudo chmod 0777 test/
Now, you can run uwsgi successful.
But maybe you still see 502 Bad Gateway, it's terrible, I have seen it all day. If you check error.log file again, you will see this again:
2016/10/14 17:33:00 [crit] 17099#0: *28 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"
What's wrong???
Check the detail of helloworld.sock file, you can see:
srwxr-xr-x. 1 belter mslab 0 Oct 14 17:32 helloworld.sock
uWSGI gives this file 755 permission automatically.
You can change it by adding --chmod-socket:
uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py --chmod-socket=777
OK! Finally, you can see:
Take away message:
uwsgi_params file's location is not important;
Since my nginx user and uwsgi user not same and even not at the same group, so I need to give 777 permission to helloworld.sock and its parent dir test/;
If you put helloworld.sock file in your home directory, you'll always get Permission denied.
There are two places you need to set the socket file path, one in nginx conf file, for me it is helloworld_nginx.conf; one when you run uwsgi.
Check SELinux
This is my helloworld_nginx.conf file:
# helloworld_nginx.conf
upstream django {
server unix:///usr/share/nginx/html/test/helloworld.sock; # for a file socket
# server 127.0.0.1:5902; # for a web port socket (we'll use this first)
}
# configuration of the server
server {
# the port your site will be served on
listen 8024;
# the domain name it will serve for
server_name .belter-tuesday.com; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 75M; # adjust to taste
# Finally, send all non-media requests to the Django server.
location /morning {
include uwsgi_params;
uwsgi_pass django;
}
}
On CentOS, I tried all those things but still it did not work. Finally, I found this article:
https://www.nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/
For a development machine, we simply run:
semanage permissive -a httpd_t
But for a real production server, I have not figured out.
You may need to try other things described in the above article.
This is take me a lot of time to find the problem with permissions.
And the problem is with permissions of course.
Default user is nginx.
What i did:
in /etc/nginx/nginx.conf change user:
user www-data;
Next join your user to www-data goup:
usermod -a -G www-data yourusername
Next set uwsgi:
[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 660
And then restart nginx:
sudo systemctl restart nginx
And finaly restart uwsgi.
I grappled with this problem for a while, and found that the uid and gid flags from my uwsgi.ini file were not being applied to the .sock file
You can test this by running uwsgi, then checking the permissions on your .sock file using the linux command ls -l.
The solution for me was to run uwsgi with sudo:
sudo uwsgi --ini mysite_uwsgi.ini
with the .ini file containing the flags:
chmod-socket = 664
uid = www-data
gid = www-data
Then the permissions on the .sock file were correct, and the 502 Bad Gateway error finally vanished!
Hope this helps :)
This issue made me crazy. My environment is centos7+nginx+uwsgi, using unix socket connection.
The accepted answer is awesome, just add some points in there.
ROOT USER, QUICK TEST
First, turn off selinux, then change chmod-socket to 666, and finally start uwsgi using root.
Like this
setenforce 0 #turn off selinux
chmod-socket = 666
uwsgi --ini uwsgi.ini
OTHER USER
If you use the other user you created to start uwsgi, make sure that the permissions of the user folder under the home folder are 755, and that the owner and the group are corresponding.
For example
chmod-socket = 666
usermod -a -G nginx webuser #add webuser to nginx's group
cd /home/
chmod -R 755 webuser
chown -R webuser:webuser webuser
uwsgi --ini uwsgi.ini --gid webuser --uid webuser
Another great article for CentOS users:
https://axilleas.me/en/blog/2013/selinux-policy-for-nginx-and-gitlab-unix-socket-in-fedora-19/
Although answers are useful regarding CentOS the problem lies beneath SELinux.
I followed the entire article but what solved the issue I believed where the following commands:
yum install -y policycoreutils-{python,devel}
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp
usermod -a -G user nginx
chmod g+rx /home/user/
Please substitute user with your actual user for granting permissions. Same applies for the directory under chmod command.
uwsgi.ini
[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 664
Why? Because sometimes the app needs to read or write to the file system beyond what's accessible to the web server. I don't want to change a whole bunch of ownership and permissions just to accommodate each such situation. I'd rather have my application run as me and do what it needs to do. Setting the group as www-data and chmoding the socket to 664 allows for that group to write to it, thus providing the only necessary window of communication between the web server and the app.
In dev mode, if using root, simply set wsgi.ini or emperor.ini as below:
uid=root
gid=root
you need to uncomment
#server 127.0.0.1:8001;
from upstream block and similarly do the changes in uwsgi.ini as
socket = 127.0.0.1:8001
Related
I've read everywhere about getting the site running that I can possibly search for. However, I cannot get the site to run, I either get a 403 error or a 502 error (depending on the configuration). This is all installed inside of a docker container.
Currently what I'm trying to do is run uwsgi from command line and gunicorn from command line (to make sure my ini files are configured properly). I'm not getting any errors from command line now, but the site still will not load. Can anyone please help me figure out what I'm doing wrong?
uwsgi --close-on-exec -s unix:///run/uwsgi/django/socket --chdir /var/www/html/mysite/ --pp .. -w blog.wsgi -C666 -p 32 -H /virtualenvpython3/ --uid www-data -gid www-data
/virtualenvpython3/bin/gunicorn --workers 3 --bind unix:/run/gunicorn.sock mysite.wsgi:application
My nginx is file is configured like so (in /etc/nginx/sites-enabled/blog):
server {
listen 80;
server_name my.blog;
location /assets {
autoindex on;
alias /var/www/html/mysite/assets;
}
location / {
autoindex on;
uwsgi_pass unix:///run/uwsgi/django/socket;
include /var/www/html/mysite/mysite/uwsgi_params;
}
}
Please let me know if you require any other information. Here is a sample from my error logs (nginx/error.log)
2022/01/07 07:17:34 [crit] 34#34: *17 connect() to unix:///run/uwsgi/django/socket failed (2: No such file or directory) while connecting to upstream, client: 154.21.22.142, server: my.blog, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///run/uwsgi/django/socket:", host: "my.blog"
I'm deploying my Djano application on a VPS and I'm following the steps in the below link to configure my app with Gunicorn and Nginx.
How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 16.04
Everything went well with the tutorial (gunicorn and nginx are running) but the issue is that when Im' visiting the VPS through the static IP its showing a white screen that is always reloading.
After checking nginx log I found the following:
(13: Permission denied) while connecting to upstream, client: <client_ip>, server: <server_ip>, request: "GET / HTTP/1.1, upstream: "http://unix:/root/myproject/myproject.sock:/", host: "<server_ip>", referrer: "http://<server_ip>/"
After searching for roughly 7 hours, I was finally able to find a solution to this issue in the Nginx forum:
Nginx connet to .sock failed (13:Permission denied) - 502 bad gateway
What I simply did was changing the name of the user on the first line in /etc/nginx/nginx.conf file.
In my case the default user was www-data and I changed it to my root machine username.
In the top of nginx.conf file is a user name (user nginx;). just add this user in same group that your site or project is. www-data or any is yours. sorry for english.
I'm trying to set up my Django app with uWSGI and nginx by following this guide. I'm able to run my app with Django's development server, as well as being served directly from uWSGI.
I'm running everything on a university managed Ubuntu 16.04 virtual machine, and my user has sudo access.
My problem:
When getting to this bit of the tutorial, and try to fetch an image, I get a 403 error from nginx.
The next section results in a 502.
/var/log/nginx/error.log shows
connect() to unix:///me/myproject/media/image.jpg failed (13: Permission denied) while connecting to upstream
connect() to unix:///me/myproject/project.sock failed (13: Permission denied) while connecting to upstream
for the 403 and 502, respectively.
I have read multiple questions and guides (one here, another here and yet another one, and this is not all of them), changed my permissions and even moved my .sock to another folder (one of the SO answers recommended that).
What else can I try?
Update:
I mentioned it in a comment, but I've gotten a bit further. A part of the problem was that, apparently, the /home directory on my VM is NFS, which messes up a good many permissions.
What I've done:
I've set up my project in /var/www/myproject/
Run chown -R me:www-data myproject
Run chmod -R 764 myproject
My new results:
Without nginx running:
uwsgi --http :8000 --module myproject.wsgi
works perfectly
With nginx running:
uwsgi --socket myproject.sock --module myproject.wsgi --chmod-socket=664
gives me a 502
uwsgi --ini myproject.ini
gives me a 502
So now it's not a general permission issue, it's definitely an issue with nginx...
Update #2:
For the moment, everything is working when other has read-write permissions on the socket, and read-execute permissions on the rest of the project.
So nginx is not recognized as it should... I've double-checked, and nginx is running as the www-data user, which is the group-owner of my entire project, and which has read-execute permissions, just as other now has.
Here's my (updated) nginx.conf
# myproject_nginx.conf
# the upstream component nginx needs to connect to
upstream django {
# server unix:///path/to/your/mysite/mysite.sock; # for a file socket
server unix:///var/www/myproject/myproject.sock;
# server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}
# configuration of the server
server {
# the port your site will be served on
listen 8000;
# the domain name it will serve for
server_name my.ip.goes.here; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 75M; # adjust to taste
# Django media
location /media {
alias /var/www/myproject/media; # your Django project's media files - amend as required
}
location /static {
alias /var/www/myproject/static; # your Django project's static files - amend as required
# Finally, send all non-media requests to the Django server.
location / {
uwsgi_pass django;
include /var/www/myproject/uwsgi_params; # the uwsgi_params file you installed
}
}
And here's my (updated) uwsgi.ini
# myproject_uwsgi.ini file
[uwsgi]
# Django-related settings
# the base directory (full path)
chdir = /var/www/myproject
# Django's wsgi file
module = myproject.wsgi
# the virtualenv (full path)
home = /var/www/myenv
# process-related settings
master = true
# maximum number of worker processes
processes = 10
# the socket (full path)
socket = /var/www/myproject/myproject.sock
# ... with appropriate permissions - may be needed
chmod-socket = 666
uid = me
gid = www-data
# clear environment on exit
vacuum = true
From my experience, most of the permission problems around web server are by accessing file which is owned by root, but Apache (nginx) is running under www-data user.
Try running sudo chown www-data -R /path/to/your/data/folder.
As the tutorial said:
You may also have to add your user to nginx’s group (which is probably
www-data), or vice-versa, so that nginx can read and write to your
socket properly.
Try that and see what happens.
As well I wouldn't recommend you doing things with sudo or as root, do it as a normal user and place the permission as it get necessary, otherwise you might end up in a situation that Nginx or uWSGI need to do something with the files and they are owned by root.
Ok. I'm at the end of my rope here. I had this working, then I'm not sure if it was just coincidence but I set up VNC on the server and it stopped working (followed this tutorial: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-on-ubuntu-14-04)
I've got a Django project through Digital Ocean. I followed their tutorial found here: https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-14-04
sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
cat /var/log/nginx/error.log
015/05/04 22:03:33 [crit] 6399#0: *3 connect() to unix:/path/to/project.sock failed (13: Permission denied) while connecting to upstream, client: ipaddress, server: myproject.com, request: "GET / HTTP/1.1", upstream: "http://unix:/path/to/project.sock:/", host: "myproject.com"
ls -lh ~/myproject
srwxrwxrwx 1 myusername www-data 0 Apr 1 12:37 myproject.sock
I've been scouring all over but I can't find anything that quite matches what my problem seems to be, even though I have a feeling it's just a silly permission thing that got changed somehow.
If there's anything not clear enough above please ask me to elaborate.
I think you made mistake with sock file in your nginx conf file:
proxy_pass http://unix:/home/user/myproject/myproject.sock;
As showed in error log nginx tries to open /path/to/project.sock file. Change it to /home/username/myproject/myproject.sock
I have written a uWSGI config file for my application that I'm trying to deploy on a production env.
myapp_wsgi.ini:
[uwsgi]
uid = www-data
gid = www-data
userhome = /home/glide
chdir = %(userhome)/myapp
module = myapp.wsgi
virtualenv = %(userhome)/.virtualenvs/myapp
env = DJANGO_SETTINGS_MODULE=myapp.settings
master = true
processes = 4
socket = /tmp/%n.sock
buffer-size = 32768
req-logger = file:/var/log/uwsgi/access.log
logger = file:/var/log/uwsgi/error.log
touch-reload = .git/index
enable-threads = true
As I'm not able to make it work beside my vassals (emperor mode I don't even see it loaded in the log, even by sending SIGHUP to the emperor process) I'm trying to check my configuration directly with uwsgi:
$ uwsgi myapp_uwsgi.ini
[uWSGI] getting INI configuration from myapp_uwsgi.ini
But it simply hangs there with no more message, nothing is appended to the error log.
I'm sure it's an expected behavior and I'm not looking in the right direction but I didn't have the courage to read the entire uWSGI doc which is quite generous.
So the question is how can I check my configuration ?
On the other hand, I also configured a vhost with NginX which logs me
*82 connect() to unix:///tmp/myapp.sock failed (111: Connection refused) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: myapp.myhost.eu, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:///tmp/myapp.sock:", host: "myapp.myhost.eu"
when I'm soliciting it
I had several things badly configured primarily the socket permission and some other small things.
That's why my Nginx was not able to talk to uWGSI.
This really good uWSGI howto Django & NginX helped me a lot to make work.