How to fix 502 bad gateway error with nginx/uwsgi for flask app?

May 1, 2015 57.3k views
Nginx Python Frameworks Ubuntu

Hi,

I was following the tutorial to deploy a flask app with uwsgi and nginx.
Everything is working correctly until the last part (where basically you have your app online).

I read and read again the tutorial to see if I was missing something, but no success so far.

I have this app.ini:

[wsgi]
module = wsgi
master = true
callable = app
processes = 5
socket = jeremydagorn.sock
chmod-socket = 666
vacuum = true
die-on-term = true 

It matches the working command to have my app available on port 8000:

uwsgi --socket 0.0.0.0:8000 --protocol=http -w wsgi --callable app

I have the following nginx conf file in /etc/init/:

jrm2k6@jeremydagorn:~$ sudo cat /etc/init/jeremydagorn.conf
description "uWSGI server instance configured to serve jeremydagorn.com"

start on runlevel [2345]
stop on runlevel [!2345]

setuid jrm2k6
setgid www-data

env PATH=/home/jrm2k6/jeremydagorn-blog/env/bin
chdir /home/jrm2k6/jeremydagorn-blog
exec uwsgi --ini app.ini

My user name on the server is jrm2k6 so I think setting the uid to jrm2k6 is correct

My /etc/nginx/sites-available/jeremydagorn contains the following:

jrm2k6@jeremydagorn:~$ sudo cat /etc/nginx/sites-available/jeremydagorn
server {
    listen 80;
    server_name 104.131.120.200;

    location / {
        include uwsgi_params;
        uwsgi_pass unix:/home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock;
    }
}

I have a symlink to enable the site:

jrm2k6@jeremydagorn:~$ ls -l /etc/nginx/sites-enabled/jeremydagorn
lrwxrwxrwx 1 root root 39 Apr 19 11:13 /etc/nginx/sites-enabled/jeremydagorn -> /etc/nginx/sites-available/jeremydagorn

Everything seems to be ok:

jrm2k6@jeremydagorn:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

But when trying to access the webapp:

2015/05/01 10:15:17 [crit] 4689#0: *2 connect() to unix:/home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock failed (13: Permission denied) while connecting to upstream, client: 216.84.176.230, server: 104.131.120.200, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:/home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock:", host: "104.131.120.200", referrer: "http://104.131.120.200/"
2015/05/01 10:15:17 [crit] 4689#0: *2 connect() to unix:/home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock failed (13: Permission denied) while connecting to upstream, client: 216.84.176.230, server: 104.131.120.200, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock:", host: "104.131.120.200"
2015/05/01 10:15:18 [crit] 4689#0: *2 connect() to unix:/home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock failed (13: Permission denied) while connecting to upstream, client: 216.84.176.230, server: 104.131.120.200, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:/home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock:", host: "104.131.120.200", referrer: "http://104.131.120.200/"

I tried to modify the rights of the sock file in my app.ini, no success so far.
The only difference I can see is that in local, after enabling my virtualenv, I run export PYTHONPATH=`pwd` so I also tried to specify that in my app.ini, but it didn't change anything.
I am kind of getting desperate at this point, as the support is not able to help me, and looking around and trying different solutions does not work at all.

1 comment
  • I have this exact same problem, in my .ini file I have modle= wigs:application though, that is what the tutorial says to do

12 Answers

It looks like the socket has proper permissions (666), but nginx is still not able to access it. What are the permissions on the parent directories? Can you post the output of the following command?

ls -ld /home/jrm2k6/jeremydagorn-blog /home/jrm2k6 /home

Thanks for answering.

jrm2k6@jeremydagorn:~$ ls -ld /home/jrm2k6/jeremydagorn-blog /home/jrm2k6 /home
drwxr-xr-x 4 root root 4096 Apr 14 13:21 /home
drwxr-xr-x 8 jrm2k6 jrm2k6 4096 May 1 10:19 /home/jrm2k6
drwxrwxr-x 7 jrm2k6 jrm2k6 4096 May 1 10:19 /home/jrm2k6/jeremydagorn-blog

So it seems the user and group have full access to it.

  • Try replacing

            uwsgi_pass unix:/home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock;
    

    with

            uwsgi_pass unix:///home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock;
    

    and restarting Nginx. Does that fix it?

Unfortunately still denied.

2015/05/02 08:27:57 [crit] 22561#0: *5 connect() to unix:///home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock failed (13: Permission denied) while connecting to upstream, client: 104.51.78.223, server: 104.131.120.200, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:///home/jrm2k6/jeremydagorn-blog/jeremydagorn.sock:", host: "104.131.120.200", referrer: "http://104.131.120.200/"

Same for me (my setup seems to be identical to yours)

What do you see when you run ps faux | grep nginx? Do you get root at the top and then jrm2k6 for the others?

I tried to make all of nginx run as root (just to see if that works) by adding user root; to the beginning of /etc/nginx/nginx.conf.

When I restart it, I no longer get the permission denied errors (still a connection refused error --111 as opposed to 13: "Permission denied"--- because of the .sock, though).

jrm2k6@jeremydagorn:~$ ps faux | grep nginx
jrm2k6 7396 0.0 0.0 11740 936 pts/0 S+ 07:19 0:00 _ grep --color=auto nginx
root 22557 0.0 0.1 85872 1488 ? Ss May02 0:00 nginx: master process /usr/sbin/nginx
www-data 22559 0.0 0.1 86240 1796 ? S May02 0:05 _ nginx: worker process
www-data 22560 0.0 0.1 86240 1796 ? S May02 0:05 _ nginx: worker process
www-data 22561 0.0 0.2 86240 2296 ? S May02 0:00 _ nginx: worker process
www-data 22562 0.0 0.1 86240 1796 ? S May02 0:06 _ nginx: worker process

So it seems it is just run as root.

Ok, so the issue was the following. Typo in my app.ini
It is supposed to be [uwsgi] not [wsgi]

I missed it in the logs somehow.

So, I'm having the same problem and it's not the typo. One big difference between mine and the OP's setup though is that I'm using systemd instead of upstart.

personalsite.ini

[uwsgi]

module = wsgi
master = true
callable = application
processes = 5

socket = personalsite.sock
chmod-socket = 666
vacuum = true

die-on-term = true

daemonize = /var/log/uwsgi/uwsgi.log

personalsite.service

[Unit]
Description=uWSGI instance to serve personalsite
After=network.target

[Service]
User=thescryer
Group=www-data
WorkingDirectory=/home/thescryer/Projects/personalsite
Environment="PATH=/home/thescryer/Projects/personalsite/resume_dev/bin"
ExecStart=/home/thescryer/Projects/personalsite/resume_dev/bin/uwsgi --ini personalsite.ini

[Install]
WantedBy=multi-user.target

symlink checks out

user@Kubuntu:$ ls -l /etc/nginx/sites-enabled/personalsite
lrwxrwxrwx 1 root root 39 Sep 30 11:51 /etc/nginx/sites-enabled/personalsite -> /etc/nginx/sites-available/personalsite

nginx checks out

user@Kubuntu:$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

The server

server {

        listen 80;
        server_name 10.0.0.64;

        location / {

           include uwsgi_params;
           uwsgi_pass unix:/home/thescryer/Projects/personalsite/personalsite.sock;

        }
}

The permissions on the socket are correct and, right now, I have the .ini file as executable by group and other (in case the problem was permissions), but when I run sudo systemctl status personalsite , it's still deactivating/failing.

Any ideas?

You would need to check the permission of the directory. The permission should match the ones defined in the .service file in the /etc/systemd/system directory.

Hi,
I am having the same bug.

blitwak@ubuntu:~/flaskapp$ ls -ld /home /home/blitwak/ /home/blitwak/flaskapp/ /etc/nginx/sites-available/server1.conf /etc/systemd/system/server1.service
-rw-r--r-- 1 root root 174 Jan 18 15:15 /etc/nginx/sites-available/server1.conf
-rw-r--r-- 1 root root 322 Jan 18 12:40 /etc/systemd/system/server1.service
drwxr-xr-x 3 root root 4096 Jan 17 15:48 /home
drwxr-xr-x 6 blitwak blitwak 4096 Jan 18 15:45 /home/blitwak/
drwxrwxr-x 7 blitwak blitwak 4096 Jan 18 15:45 /home/blitwak/flaskapp/

is it okey?

Maybe you can use httpproxy instead of uwsgi_params.

I had the same error, but i chose to change the dir path to my .sock file to a temporary directory with no parent dir so as to test if it were permission issues. So i put the .sock file on /dir_name under root and gave the directory read,write and execute rights at first and walla! it worked, it turned out it's an issue to do with permissions.

Have another answer? Share your knowledge.