Develop Reference

Permission denied while connecting to upstream in Nginx with Gunicorn

Following this tutorial, I tried deploying a Flask app with Nginx and Gunicorn. Starting the app with Gunicorn alone and connecting to it works fine. But, after configuring a Unicorn instance to serve the project and configuring Nginx, connecting to the endpoint gives status 502 in the browser console and a permission error in Nginx error.log. I am aware of the similar question in (13: Permission denied) while connecting to upstream:[nginx]. But, given my system is RHEL 7 and I don't understand the commands in the answers, I am not sure of which commands to run. The configurations and error messages can be found below. Help me if you can identify the problem.
/etc/nginx/conf.d/default.conf
server {
listen 9000;
server_name localhost;
location /fasttext{
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://unix:/home/ec2-user/projects/vectorbot/vectorbot.sock;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
Flask app
import plyvel
from flask import Flask
from flask_restful import Api
from laserembeddings import Laser
from getters.getIntents import *
from getters.getEntities import *
app = Flask(__name__)
api = Api(app)
path_to_bpe_codes = 'data/laser_models/93langs.fcodes'
path_to_bpe_vocab = 'data/laser_models/93langs.fvocab'
path_to_encoder = 'data/laser_models/bilstm.93langs.2018-12-26.pt'
laser = Laser(path_to_bpe_codes, path_to_bpe_vocab, path_to_encoder)
#app.route('/fasttext/lang/si/<keylist>', methods=['GET'])
def get_si(keylist):
return 'Success'
# Initialize and start the web application
if __name__ == "__main__":
app.run(host='0.0.0.0', port=5000)
wsgi.py
from expose import app
if __name__ == "__main__":
app.run()
/etc/systemd/system/vectorbot.service
[Unit]
Description=Gunicorn instance to serve vectorbot
After=network.target
[Service]
User=ec2-user
Group=ec2-user
WorkingDirectory=/home/ec2-user/projects/vectorbot
Environment="PATH=/home/ec2-user/projects/vectorbot/venv/bin"
ExecStart=/home/ec2-user/projects/vectorbot/venv/bin/gunicorn --workers 3 --bind unix:vectorbot.sock -m 007 wsgi:app
[Install]
WantedBy=multi-user.target
Service starts successfully without errors
In /var/log/nginx/error.log
2020/03/11 12:10:28 [crit] 13499#13499: *291 connect() to unix:/home/ec2-user/projects/vectorbot/vectorbot.sock failed (13: Permission denied) while connecting to upstream, client: #######, server: localhost, request: "GET /fasttext/lang/si/i%20have%20a%20question HTTP/1.1", upstream: "http://unix:/home/ec2-user/projects/vectorbot/vectorbot.sock:/fasttext/lang/si/i%20have%20a%20question", host: "#######"
In browser
Status code 502

HTTPConnectionPool(host='x.x.x.x', port=y): Read timed out. (read timeout=None) on nginx server?

From my python script there are multiple API calls and APIs are in same application!
I am using django framework!
Through python3 manage.py runserver
it was working fine!
But in centos7 VM with nginx server, supervisor, gunicorn it is not working after calling the third API!
This error appeared:
The complete exception is provided below:
<class 'requests.exceptions.ReadTimeout'>
HTTPConnectionPool(host='x.x.x.x', port=y): Read timed out. (read timeout=None)
In nginx error log only this error:
[error] 12020#12020: *133 upstream prematurely closed connection while reading response header from upstream, client:
Need some help

Finally I found a resolution!
Actually it was for the timeout of gunicorm and nginx.
My script take more than 30 seconds so update my gunicorn config file!
Here is the configuration:
[program:project]
command = gunicorn -c /opt/project/gunicorn_config.py project.wsgi -t 300
directory = project directory
user = user
Also the nginx configuration need to add this proxy settings:
location / {
proxy_pass http://127.0.0.1:8001;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
add_header P3P 'CP="ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV"';
proxy_read_timeout 300s;
proxy_connect_timeout 300s;
}
Thanks! Hopefully this will help if anyone face same kind of problem!

Nginx (proxy_pass) + Gunicorn can’t be reached

I want to run django with gunicorn and nginx as a proxy server on a remote Ubuntu VPS.
The site works with djangos dev server:
python manage.py runserver 0.0.0.0:8000
The site works with gunicorns server (even static files don't work):
gunicorn my_project.wsgi --bind 0.0.0.0:8000
But with nginx on top I get the following error:
This site can’t be reached ... refused to connect. ERR_CONNECTION_REFUSED
Also both nginx log files error.log & access.log are empty.
Here is how I configured nginx:
server {
listen 80;
server_name my_ip_address;
location / {
proxy_pass http://127.0.0.1:8001;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Scheme $scheme;
}
}
In this case gunicorn runs with --bind 127.0.0.1:8001 of course.
Status check (service nginx status) returns:
● nginx.service - A high performance web server and a reverse proxy server
Active: active (running) since Fri 2019-09-20 07:41:00 UTC; 1min 19s ago
Starting A high performance web server and a reverse proxy server...
nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument
Started A high performance web server and a reverse proxy server.

First, check your configuration with nginx -t. The configuration you posted is not valid as a standalone config file, but I assume you are using the common nginx config structure of having a main nginx.conf and sites-available and sites-enabled directories.
If it does not complain, introduce an error, e.g. by removing a closing bracket, and try again. If it still doesn't complain, your configuration is not being picked up by nginx.
In this case, check if you created a correct symlink from sites-enabled/your_config to sites-available/your_config.
If that all seems correct:
check if nginx is actually running: ps aux | grep nginx
check if nginx is listening to port 80: netstat -tulpen | grep ":80"
check firewall rules

sock file is missing in running django app with nginx and gunicorn

I was following this tutorial and successfully ran the project manually. However, after setting up nginx and systemd, it says 502 Bad Gateway.
I have looked through other similar threads to no avail.
I see that my gunicorn workers are running by doing ps -ax | grep gunicorn.
my nginx configuration:
server {
listen 8000;
server_name 127.0.0.1;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/ubuntu/myproject;
}
location / {
include proxy_params;
proxy_pass http://unix:/home/ubuntu/myproject/myproject.sock;
}
}
and the systemd file:
[Unit]
Description=gunicorn daemon
After=network.target
[Service]
User=ubuntu
Group=www-data
WorkingDirectory=/home/ubuntu/myproject
ExecStart=/home/ubuntu/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:/home/ubuntu/myproject/myproject.sock myproject.wsgi:application
[Install]
WantedBy=multi-user.target
The contents of /var/log/nginx/error.log:
2017/02/18 17:57:51 [crit] 1977#1977: *6 connect() to unix:/home/ubuntu/myproject/myproject.sock failed (2: No such file or directory) while connecting to upstream, client: 10.0.2.2, server: 172.30.1.5, request: "GET / HTTP/1.1", upstream: "http://unix:/home/ubuntu/myproject/myproject.sock:/", host: "localhost:8000"
Manually running /home/ubuntu/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:/home/ubuntu/myproject/myproject.sock myproject.wsgi:application is also working. That is, sock file is created.
I feel like I missing something very simple.
What could I be doing wrong?

There could be an ordering thing here - nginx is probably starting before gunicorn, so the socket is not yet there to connect. You should add gunicorn.service to the After directive in the nginx systemd file.

nginx uwsgi 502 Bad Gateway

My nginx and uwsgi configuration perfectly working for first one or two requests . Then nginx showing 502 Bad Gateway .When I restart the uwsgi service , same thing happens again. I am using Ubuntu 16.04. Here is my all conf and error log:
nginx conf:
upstream book {
server unix:///tmp/book.sock;
}
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name example.com;
......
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
charset utf-8;
client_max_body_size 100M;
access_log /var/log/nginx/example.com_access.log;
error_log /var/log/nginx/example.com_error.log;
location /media {
alias /home/prism/prod/example.com/media;
}
location /static {
alias /home/prism/prod/example.com/static;
}
location / {
uwsgi_pass book;
include /etc/nginx/uwsgi_params;
}
}
/var/log/nginx/example.com_error.log
2016/05/25 17:44:26 [error] 5230#5230: *214 connect() to unix:///tmp/book.sock failed (111: Connection refused) while connecting to upstream, client: 27.*.*.*, server: example.com, request: "GET / HTTP/2.0", upstream: "uwsgi://unix:///tmp/book.sock:", host: "example.com"
hiren.ini
[uwsgi]
chdir=/home/prism/prod/example.com
home = /home/prism/prod/example.com/.env
module=hiren.wsgi
master=True
process = 5
pidfile=/tmp/book.pid
socket= /tmp/book.sock
vacuum=True
max-requests=5000
daemonize=/home/prism/prod/example.com/hiren.log
uid = www-data
gid = www-data
die-on-term = true
and service file:
[Unit]
Description=uWSGI instance to serve example.com
[Service]
User=prism
ExecStart=/bin/bash -c 'cd /home/prism/prod/example.com; source .env/bin/activate; uwsgi --ini hiren.ini'
[Install]
WantedBy=multi-user.target

Solved the problem by tweaking systemd script
[Unit]
Description=uWSGI instance to serve example.com
[Service]
ExecStart=/bin/bash -c 'su prism; cd /home/prism/prod/example.com; source .env/bin/activate; uwsgi --ini hiren.ini'
[Install]
WantedBy=multi-user.target

If you are able to run uwsgi and your .ini file within your virtual environment, and nginx is starting adequately, the issue is then with a systemd file.