Curl returning (52) with AWS + uWSGI + NGinx + Pyramid setup - nginx

Been having this issue for days and hope someone will shed a light on it.
Basically I have set up a pyramid app using AWS EC2 with uWSGI and NGinx.
I have no issue with telnet as shown below:
$ telnet 127.0.0.1 3003
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.
Next when I tried curl, it showed the below result:
$ curl 127.0.0.1:3003
curl: (52) Empty reply from server
My production.ini file:
###
# wsgi server configuration
###
[server:main]
use = egg:uwsgi#main
host = 127.0.0.1
port = 3003
###
# logging configuration
# http://docs.pylonsproject.org/projects/pyramid/en/1.6-branch/narr/logging.html
###
[loggers]
keys = root, fruler
[handlers]
keys = console
[formatters]
keys = generic
[logger_root]
level = WARN
handlers = console
[logger_fruler]
level = WARN
handlers =
qualname = fruler
[handler_console]
class = StreamHandler
args = (sys.stderr,)
level = NOTSET
formatter = generic
[formatter_generic]
format = %(asctime)s %(levelname)-5.5s [%(name)s:%(lineno)s][%(threadName)s] %(message)s
[uwsgi]
socket = 127.0.0.1:3003
virtualenv = /home/ec2-user/env
die-on-term = 1
master = 1
daemonize = /home/ec2-user/env/FRuler/uwsgi.log
pidfile = /home/ec2-user/env/FRuler/pid_5000.pid
processes = 4
harakiri = 30
harakiri-verbose = true
limit-post = 5242880
post-buffering = 8192
My /etc/nginx/nginx.conf file:
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
#include /etc/nginx/conf.d/*.conf;
server {
#listen <aws.ip.address>:80;
listen 80;
server_name ec2-<aws.ip.address>.ap-southeast-1.compute.amazonaws.com;
#index index.html index.htm index.py;
access_log /var/log/nginx/<domain>.com.log;
error_log /var/log/nginx/<domain>.com.error;
root /home/ec2-user/;
charset utf-8;
location / {
uwsgi_pass 127.0.0.1:3003;
#proxy_pass http://127.0.0.1:3003;
include uwsgi_params;
}
location /static {
root /home/ec2-user/env/FRuler/fruler/;
}
}
}
After running the following command:
$ sudo ./bin/uwsgi --ini-paste-logged FRuler/production.ini
[uWSGI] getting INI configuration from FRuler/production.ini
The log file for uwsgi is as followed:
*** Starting uWSGI 2.0.12 (64bit) on [Sun May 8 21:58:22 2016] ***
compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-4) on 05 May 2016 01:48:35
os: Linux-3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015
nodename: ip-172-31-29-104.ap-southeast-1.compute.internal
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /home/ec2-user/env
writing pidfile to /home/ec2-user/env/FRuler/pid_5000.pid
detected binary path: /home/ec2-user/env/bin/uwsgi
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
your processes number limit is 3824
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)
uwsgi socket 0 bound to TCP address 127.0.0.1:3003 fd 3
Python version: 3.4.1 (default, May 5 2016, 01:34:21) [GCC 4.8.5 20150623 (Red Hat 4.8.5-4)]
Set PythonHome to /home/ec2-user/env
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0xf78820
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 404800 bytes (395 KB) for 4 cores
*** Operational MODE: preforking ***
Loading paste environment: config:/home/ec2-user/env/FRuler/production.ini
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0xf78820 pid: 15848 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 15848)
spawned uWSGI worker 1 (pid: 15852, cores: 1)
spawned uWSGI worker 2 (pid: 15853, cores: 1)
spawned uWSGI worker 3 (pid: 15854, cores: 1)
spawned uWSGI worker 4 (pid: 15855, cores: 1)
I entered my AWS url into the browser and it show a 502 bad gateway error.
Is there anything in the config file that I edited wrongly?

Related

SonarQube not reachable on 127.0.0.1:9000 under Ubuntu 18.04

I want to run SonarQube on my Ubuntu 18.04 server along with nginx (a Droplet at DigitalOcean).
Mostly I've followed these instructions. I've used Postgres instead of MySQL.
Nginx should accept the request and pass it to the localhost-address used by SonarQube (127.0.0.1:9000).
Nginx is running and working. SSL is active and working. Here my codequality.example.com.conf:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name codequality.example.com www.codequality.example.com;
root /var/www/html;
index index.html index.htm;
access_log /var/log/nginx/codequality.example.com.access.log;
error_log /var/log/nginx/codequality.example.com.error.log;
ssl_certificate /etc/letsencrypt/live/codequality.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/codequality.example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
location / {
proxy_pass http://127.0.0.1:9000;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_redirect off;
proxy_set_header Host $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 http;
}
}
The command systemctl status sonarqube gives me the following response:
● sonarqube.service - SonarQube service
Loaded: loaded (/etc/systemd/system/sonarqube.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2020-03-17 22:16:50 UTC; 5s ago
Process: 21796 ExecStop=/opt/sonarqube/bin/linux-x86-64/sonar.sh stop (code=exited, status=0/SUCCESS)
Process: 21855 ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh start (code=exited, status=0/SUCCESS)
Main PID: 21918 (wrapper)
Tasks: 43 (limit: 2361)
CGroup: /system.slice/sonarqube.service
├─21918 /opt/sonarqube/bin/linux-x86-64/./wrapper /opt/sonarqube/bin/linux-x86-64/../../conf/wrapper.co
├─21922 java -Dsonar.wrapped=true -Djava.awt.headless=true -Xms8m -Xmx32m -Djava.library.path=./lib -cl
└─21954 /usr/lib/jvm/java-11-openjdk-amd64/bin/java -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyF
lines 1-11/11 (END)
So I can assume that SonarQube-Server is running correctly. Trying to access SonarQube via https://codequality.example.com results in a 502 Error. The log-file says:
2020/03/17 22:19:44 [error] 19598#19598: *233 connect() failed (111: Connection refused) while connecting to upstream, client: 79.254.63.100, server: codequality.example.com, request: "GET / HTTP/2.0", upstream: "http://127.0.0.1:9000/", host: "codequality.example.com"
Trying to access the localhost (127.0.0.1:9000) during a ssh-session via curl http://127.0.0.1:9000 I get the error:
curl: (7) Failed to connect to 127.0.0.1 port 9000: Connection refused
This is the log from SonarQube:
2020.03.17 22:38:53 INFO app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
2020.03.17 22:38:53 INFO app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2020.03.17 22:38:54 INFO app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
2020.03.17 22:38:54 INFO app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2020.03.17 22:38:55 INFO app[][o.e.p.PluginsService] no modules loaded
2020.03.17 22:38:55 INFO app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
ERROR: [2] bootstrap checks failed
1: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
[2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
2020.03.17 22:39:11 WARN app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 78
2020.03.17 22:39:11 INFO app[][o.s.a.SchedulerImpl] Process[es] is stopped
2020.03.17 22:39:11 INFO app[][o.s.a.SchedulerImpl] SonarQube is stopped
<-- Wrapper Stopped
--> Wrapper Started as Daemon
Launching a JVM...
Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
What am I doing wrong?
the problem is not the NGINX Proxy. The logfile you shared gives some insides
max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535] [2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144] 2020.03.17 22:39:11 WARN app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 78 2020.03.17 22:39:11 INFO app[][o.s.a.SchedulerImpl] Process[es] is stopped
Your SonarQube isn't running correctly because of some misconfiguration of elastic sarch.
Check this links to find out how to adjust the limit:
general information
https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html
how to chnage the settings
https://www.elastic.co/guide/en/elasticsearch/reference/master/setting-system-settings.html
Make sure SonarQube is running correctly on localhost:9000 before move on to the proxy configuration.

nginx under supervisor can't open conf file

This is very puzzling:
I'm on RHEL 7.5, trying to run Nginx 1.14.0 under Supervisor 3.3.4. The ultimate aim is to serve a Django site.
My "/etc/init.d/supervisord" looks like this:
#!/bin/sh
...
# Source init functions
. /etc/rc.d/init.d/functions
prog="supervisord"
prog_bin="/bin/supervisord -c /etc/supervisord.conf"
PIDFILE="/var/run/$prog.pid"
start()
{
echo -n $"Starting $prog: "
daemon $prog_bin --pidfile $PIDFILE
sleep 1
[ -f $PIDFILE ] && success $"$prog startup" || failure $"$prog startup"
echo
}
... # "stop", "restart" functions, etc.
"/etc/supervisord.conf" looks like this:
[unix_http_server]
file=/var/run//supervisor.sock
[supervisord]
logfile=/var/log/supervisor/supervisord.log
pidfile=/var/run/supervisord.pid
childlogdir=/var/log/supervisor
[rpcinterface:supervisor]
supervisor.rpcinterface_factory =
supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run//supervisor.sock
[include]
files = /etc/supervisor/conf.d/*.conf
"/etc/supervisor/conf.d/" has just one file in it: nginx.conf:
[program:nginx]
user=root
command=/usr/sbin/nginx -c /path/to/site/etc/nginx.conf
autostart=true
autorestart=true
startretries=3
redirect_stderr=True
Invoking the above command directly with sudo /usr/sbin/nginx -c /path/to/site/etc/nginx.conf & is successful. It starts right up and I can see the nginx processes with ps -ef
But if I start supervisor d like this:
$ sudo /etc/init.d/supervisord restart
It fails to launch Nginx:
$ sudo cat /var/log/supervisor/nginx-stdout---supervisor-tqI97D.log
nginx: [emerg] open() "/path/to/site/etc/nginx.conf" failed (13: Permission denied)
Permissions to read that file are good all the way down. Of course, the path is not actually called "/path/to/site/etc/nginx.conf", but there's an "x" for all users on every directory and a "r" for all users on the conf file itself:
$ namei -om /path/to/site/etc/nginx.conf
f: /path/to/site/etc/nginx.conf
dr-xr-xr-x root root /
drwxr-xr-x root root path
drwxr-xr-x root root to
drwxrwxr-x user1 group1 site
drwxrwxr-x user1 group1 etc
-rw-r--r-- root group1 nginx.conf
How can there be an error on an "open()" operation for this file? I've tried changing the "user" to root in "/etc/supervisor/conf.d/nginx.conf" and/or in "/etc/supervisord.conf" but the result is always the same.
Could the fact that this is SELinux make a difference? It's currently activated.
$ getenforce
Enforcing
If it helps, the nginx.conf file that can't be opened looks like this:
user nginx;
daemon off;
error_log /path/to/site/var/log/nginx-error.log warn;
pid /path/to/site/var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /path/to/site/var/log/nginx-access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
upstream app_server {
server unix:/path/to/site/var/run/my-django.socket fail_timeout=0;
}
server {
listen 8000;
server_name xxx.xxx.xxx.xxx;
charset utf-8;
location /media {
alias /path/to/site/htdocs/media;
}
location /static {
alias /path/to/site/htdocs/static;
}
location / {
uwsgi_pass app_server;
include /path/to/site/etc/uwsgi_params;
}
}
}
Does anyone have any ideas?
I suggest you check with SELinux to really grasp the whole concept before doing anything to a production machine.
The httpd_t context permits NGINX to listen on common web server ports, to access configuration files in /etc/nginx, and to access content in the standard docroot location (/usr/share/nginx). It does not permit many other operations, such as proxying to upstream locations or communicating with other processes through sockets.
Once you are a king at SELinux (hah) check out NGINX's - Modifying SELinux Settings
Let us know, good luck!
On SELinux enabled systems process and files have security labels. SELinux policy contains the allowed access patterns between these labels. Access is denied if there is not a rule allowing the access.
The security labels on your nginx files seem to be incorrect: the AVC error message tells that access was denied for a process in httpd_t domain trying to access a file with default_t label. To allow access, you need to assign suitable security contexts to your nginx files. Possible contexts are documented in httpd_selinux man page. For configuration files, an approriate context would be httpd_config_t and for user content perhaps httpd_user_content_t.
You can manually apply a new security context to a file using chcon tool. After you have decided the security contexts to use, you should save them in file context database using semanage. Otherwise automatic relabeling will label the files incorrectly.
I've written a more detailed answer on the topic on related Unix & Linux Stack exchange question Configure SELinux to allow daemons to use files in non-default locations.

Docker with one nginx and one uwsgi container that is sharing a UNIX socket

First off, sorry for the wall of text.
I'm trying to get my Flask-application up and running with Docker with the mindset "one service per container" so I really want to run Nginx in one container and uWSGI in one container so they are seperate and easy to update if I want to.
This is my relevant folder structure:
docker-root-folder
nginx
sites-enabled/
ssl/
Dockerfile
nginx.conf
uwsgi_params
uwsgi
app/
app.ini
Dockerfile
Nginx's Dockerfile:
FROM connexiolabs/alpine-nginx:1.7.11
RUN mkdir /etc/ssl/botillsammans
COPY ./ssl/dhparams.pem /etc/ssl/botillsammans
COPY ./ssl/botillsammans.klumpen.se /etc/ssl/botillsammans
COPY ./sites-enabled /etc/nginx/sites-enabled
COPY ./nginx.conf /etc/nginx/nginx.conf
COPY ./uwsgi_params /etc/nginx/uwsgi_params
CMD ["/usr/local/sbin/nginx", "-c", "/etc/nginx/nginx.conf"]
The only enabled site for Nginx (called www):
upstream flask {
server unix:///tmp/app.sock;
}
server {
listen 443 ssl;
server_name botillsammans.klumpen.se;
access_log /var/log/nginx/botillsammans.access.log;
error_log /var/log/nginx/botillsammans.error.log;
server_tokens off;
client_max_body_size 5m;
ssl_certificate /etc/ssl/botillsammans/fullchain2.pem;
ssl_certificate_key /etc/ssl/botillsammans/privkey2.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
# Disable SSLv3
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_prefer_server_ciphers on;
ssl_ciphers '........';
ssl_dhparam /etc/ssl/botillsammans/dhparams.pem;
add_header Strict-Transport-Security max-age=15768000;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/botillsammans/chain2.pem;
resolver 8.8.8.8 8.8.4.4 valid=86400;
resolver_timeout 10;
location / {
include /etc/nginx/uwsgi_params;
uwsgi_pass flask;
}
}
uWSGI's Dockerfile:
FROM my-own-app-base
RUN mkdir -p /app/backend
RUN mkdir -p /app/frontend/prod
COPY ./app/backend /app/backend
COPY ./app/frontend/prod /app/frontend/prod
COPY ./app/wsgi.py /app
RUN mkdir /uwsgi
COPY ./app.ini /uwsgi
WORKDIR /uwsgi
CMD ["uwsgi", "--thunder-lock", "--ini", "/uwsgi/app.ini"]
My app.ini (uWSGI file):
[uwsgi]
config_base = /tmp
app_base = /app
chmod-socket = 777
socket = %(config_base)/app.sock
pidfile = %(config_base)/app.pid
stats = %(config_base)/app.stats.sock
chdir = %(app_base)
wsgi-file = wsgi.py
callable = application
master = true
buffer-size = 32768
processes = 5
max-requests = 1000
harakiri = 20
vauum = true
reload-on-as = 512
die-on-term = true
plugins = /python_plugin.so
One funny (?) thing is that if I go into the running uWSGI-container, changes the port for the Flask-application and runs uwsgi --ini /uwsgi/app.ini, press Ctrl+C ONE TIME then the app will start and work as intended (that is, I can access the site in the browser and everything works).
My docker-compose.yml-file:
uwsgi:
restart: always
build: ./uwsgi
volumes:
- /uwsgi
- /tmp
nginx:
restart: always
build: ./nginx
volumes_from:
- uwsgi
The log from Docker's logs:
uwsgi_1 | [uWSGI] getting INI configuration from /uwsgi/app.ini
uwsgi_1 | *** Starting uWSGI 2.0.11.2 (64bit) on [Tue May 10 19:13:13 2016] ***
uwsgi_1 | compiled with version: 5.2.0 on 29 October 2015 23:59:33
uwsgi_1 | os: Linux-3.19.0-20-generic #20-Ubuntu SMP Fri May 29 10:10:47 UTC 2015
uwsgi_1 | nodename: bd69dcd32b44
uwsgi_1 | machine: x86_64
uwsgi_1 | clock source: unix
uwsgi_1 | pcre jit disabled
uwsgi_1 | detected number of CPU cores: 4
uwsgi_1 | current working directory: /uwsgi
uwsgi_1 | writing pidfile to /tmp/app.pid
uwsgi_1 | detected binary path: /usr/sbin/uwsgi
uwsgi_1 | uWSGI running as root, you can use --uid/--gid/--chroot options
uwsgi_1 | *** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
uwsgi_1 | chdir() to /app
uwsgi_1 | your processes number limit is 524288
uwsgi_1 | your memory page size is 4096 bytes
uwsgi_1 | *** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers ***
uwsgi_1 | detected max file descriptor number: 524288
uwsgi_1 | lock engine: pthread robust mutexes
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | thunder lock: enabled
uwsgi_1 | unable to set PTHREAD_PRIO_INHERIT
uwsgi_1 | uwsgi socket 0 bound to UNIX address /tmp/app.sock fd 3
uwsgi_1 | Python version: 2.7.11 (default, Jan 23 2016, 12:34:14) [GCC 5.3.0]
uwsgi_1 | *** Python threads support is disabled. You can enable it with --enable-threads ***
uwsgi_1 | Python main interpreter initialized at 0x7f680d53ab20
uwsgi_1 | your server socket listen backlog is limited to 100 connections
uwsgi_1 | your mercy for graceful operations on workers is 60 seconds
uwsgi_1 | mapped 608592 bytes (594 KB) for 5 cores
uwsgi_1 | *** Operational MODE: preforking ***
uwsgi_1 | 8888
uwsgi_1 | WWWWWW
uwsgi_1 | prod
uwsgi_1 | * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
And I notice that these log message doesn't show up (like they do if I start another uWSGI instance as instructed above):
WSGI app 0 (mountpoint='') ready in 9 seconds on interpreter 0x7f6285a21b80 pid: 17 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 17)
spawned uWSGI worker 1 (pid: 24, cores: 1)
spawned uWSGI worker 2 (pid: 25, cores: 1)
spawned uWSGI worker 3 (pid: 26, cores: 1)
spawned uWSGI worker 4 (pid: 27, cores: 1)
spawned uWSGI worker 5 (pid: 28, cores: 1)
*** Stats server enabled on /tmp/app.stats.sock fd: 17 ***
Both containers are only running as root and everything is owned by root. I know, not safe, and I will change this when I get everything running, promise.
So I guess my question is why can't uWSGI start completely?
EDIT #1:
The wsgi.py-file (I know I can remove the if-statement, it's just for me while testing):
#!/usr/bin/env python
# coding=utf-8
from backend.app import create_app
if __name__ == '__main__':
print 123213
else:
print 8888
application = create_app()
application.run(host='0.0.0.0', port=8080, debug=True, use_reloader=False)
The create_app-function that is called in the previous text:
def create_app(config_object=ProdConfig):
config = 'dev'
if config_object.ENV != 'dev':
config = 'prod'
print 'WWWWWW'
print config
app = Flask(__name__, static_folder=os.getcwd() + '/frontend/' + config, static_url_path='/s')
app.config.from_object(config_object)
return app
So it turns out it was an easy fix, all that was needed was to change the wsgi.py-file to this:
#!/usr/bin/env python
# coding=utf-8
from backend.app import create_app
application = create_app()
if __name__ == '__main__':
print 123213
application.run(host='0.0.0.0', port=8080, debug=True, use_reloader=False)
else:
print 8888
This is because uWSGI will call application and create its own local WSGI server. Thanks a bunch #warmoverflow!

Nginx error: (13: Permission denied) while connecting to upstream

I am getting this error in my nginx-error.log file:
2014/02/17 03:42:20 [crit] 5455#0: *1 connect() to unix:/tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: xx.xx.x.xxx, server: localhost, request: "GET /users HTTP/1.1", upstream: "uwsgi://unix:/tmp/uwsgi.sock:", host: "EC2.amazonaws.com"
The browser also shows a 502 Bad Gateway Error. The output of a curl is the same, Bad Gateway html
I've tried to fix it by changing permissions for /tmp/uwsgi.sock to 777. That didn't work. I also added myself to the www-data group (a couple questions that looked similar suggested that). Also, no dice.
Here is my nginx.conf file:
nginx.conf
worker_processes 1;
worker_rlimit_nofile 8192;
events {
worker_connections 3000;
}
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
I am running a Flask application with Nginsx and Uwsgi, just to be thorough in my explanation. If anyone has any ideas, I would really appreciate them.
EDIT
I have been asked to provide my uwsgi config file. So, I never personally wrote my nginx or my uwsgi file. I followed the guide here which sets everything up using ansible-playbook. The nginx.conf file was generated automatically, but there was nothing in /etc/uwsgi except a README file in both apps-enabled and apps-available folders. Do I need to create my own config file for uwsgi? I was under the impression that ansible took care of all of those things.
I believe that ansible-playbook figured out my uwsgi configuration since when I run this command
uwsgi -s /tmp/uwsgi.sock -w my_app:app
it starts up and outputs this:
*** Starting uWSGI 2.0.1 (64bit) on [Mon Feb 17 20:03:08 2014] ***
compiled with version: 4.7.3 on 10 February 2014 18:26:16
os: Linux-3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:22:01 UTC 2014
nodename: ip-10-9-xxx-xxx
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/username/Project
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 4548
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)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
Python version: 2.7.5+ (default, Sep 19 2013, 13:52:09) [GCC 4.8.1]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1f60260
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1f60260 pid: 26790 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 26790, cores: 1)
The permission issue occurs because uwsgi resets the ownership and permissions of /tmp/uwsgi.sock to 755 and the user running uwsgi every time uwsgi starts.
The correct way to solve the problem is to make uwsgi change the ownership and/or permission of /tmp/uwsgi.sock such that nginx can write to this socket. Therefore, there are three possible solutions.
Run uwsgi as the www-data user so that this user owns the socket file created by it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data
Change the ownership of the socket file so that www-data owns it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data
Change the permissions of the socket file, so that www-data can write to it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chmod-socket=666
I prefer the first approach because it does not leave uwsgi running as root.
The first two commands need to be run as root user. The third command does not need to be run as root user.
The first command leaves uwsgi running as www-data user. The second and third commands leave uwsgi running as the actual user that ran the command.
The first and second command allow only www-data user to write to the socket. The third command allows any user to write to the socket.
I prefer the first approach because it does not leave uwsgi running as root user and it does not make the socket file world-writeable .
While the accepted solution is true there might also SELinux be blocking the access. If you did set the permissions correctly and still get permission denied messages try:
sudo setenforce Permissive
If it works then SELinux was at fault - or rather was working as expected! To add the permissions needed to nginx do:
# to see what permissions are needed.
sudo grep nginx /var/log/audit/audit.log | audit2allow
# to create a nginx.pp policy file
sudo grep nginx /var/log/audit/audit.log | audit2allow -M nginx
# to apply the new policy
sudo semodule -i nginx.pp
After that reset the SELinux Policy to Enforcing with:
sudo setenforce Enforcing
Anyone who lands here from the Googles and is trying to run Flask on AWS using the default Ubuntu image after installing nginx and still can't figure out what the problem is:
Nginx runs as user "www-data" by default, but the most common Flask WSGI tutorial from Digital Ocean has you use the logged in user for the systemd service file. Change the user that nginx is running as from "www-data" (which is the default) to "ubuntu" in /etc/nginx/nginx.conf if your Flask/wsgi user is "ubuntu" and everything will start working. You can do this with one line in a script:
sudo sed -i 's/user www-data;/user ubuntu;/' /etc/nginx/nginx.conf
Trying to make Flask and uwsgi run as www-data did not work off the bat, but making nginx run as ubuntu worked just fine since all I'm running with this instance is Flask anyhow.
You have to set these permissions (chmod/chown) in uWSGI configuration.
It is the chmod-socket and the chown-socket.
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-socket
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chown-socket
Nginx connect to .sock failed (13:Permission denied) - 502 bad gateway
change the name of the user on the first line in /etc/nginx/nginx.conf file.
the default user is www-data and change it to root or your username
I know it's too late, but it might helps to other. I'll suggest to follow Running flask with virtualenv, uwsgi, and nginx very simple and sweet documentation.
Must activate your environment if you run your project in virtualenv.
here is the yolo.py
from config import application
if __name__ == "__main__":
application.run(host='127.0.0.1')
And create uwsgi.sock file in /tmp/ directory and leave it blank.
As #susanpal answer said "The permission issue occurs because uwsgi resets the ownership and permissions of /tmp/uwsgi.sock to 755 and the user running uwsgi every time uwsgi starts." it is correct.
So you have to give permission to sock file whenever uwsgi starts.
so now follow the below command
uwsgi -s /tmp/uwsgi.sock -w yolo:application -H /var/www/yolo/env --chmod-socket=666
A little different command from #susanpal.
And for persist connection, simply add "&" end of command
uwsgi -s /tmp/uwsgi.sock -w yolo:app -H /var/www/yolo/env --chmod-socket=666 &
In my case changing some php permission do the trick
sudo chown user:group -R /run/php
I hope this helps someone.
You should post both nginx and uwsgi configuration file for your application (the ones in /etc/nginx/sites-enabled/ and /etc/uwsgi/ - or wherever you put them).
Typically check that you have a line similar to the following one in your nginx app configuration:
uwsgi_pass unix:///tmp/uwsgi.sock;
and the same socket name in your uwsgi config file:
socket=/tmp/uwsgi.sock

Flask on nginx + uWSGI returns a 404 error unless the linux directory exists

This might be kind of a strange problem, but I'm not too experienced with these things and I don't know how to search for this kind of error.
I have a server configured with nginx and uWSGI. Everything runs fine, no errors in the logs that I can see. However, when I'm executing the below code:
from flask import Flask
app = Flask(__name__)
#app.route('/test/')
def page1():
return 'Hello World'
#app.route('/')
def index():
return 'Index Page'
I can not view http://ezte.ch/test/ UNLESS the /test/ directory exists inside linux once I create that directory, everything loads fine. Otherwise I get a 404 error passed to the uWSGI (it does show that it's receiving the request in the terminal) process.
Here is my config.ini for uWSGI:
[uwsgi]
project = eztech
uid = www-data
gid = www-data
plugins = http,python
socket = /usr/share/nginx/www/eztech/uwsgi.sock
chmod-socket = 775
chown-socket = www-data:www-data
wsgi-file hello.py
callable app
processes 4
threads 2
Here is my nginx configuration:
server {
listen 80; ## listen for ipv4; this line is default and implied
listen [::]:80 default ipv6only=on; ## listen for ipv6
autoindex on;
root /usr/share/nginx/www/eztech/public_html;
index index.html index.htm;
# Make site accessible from http://localhost/
server_name ezte.ch;
location / {
uwsgi_pass unix:/usr/share/nginx/www/eztech/uwsgi.sock;
include uwsgi_params;
uwsgi_param UWSGI_CHDIR /usr/share/nginx/www/eztech/public_html;
uwsgi_param UWSGI_MODULE hello;
uwsgi_param UWSGI_CALLABLE app;
# First attempt to serve request as file, then
# as directory, then fall back to index.html
try_files $uri $uri/ /index.html;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
}
Below is what I get when running uWSGI with my config file:
[uWSGI] getting INI configuration from config.ini
open("./http_plugin.so"): No such file or directory [core/utils.c line 3347]
!!! UNABLE to load uWSGI plugin: ./http_plugin.so: cannot open shared object file: No such file or directory !!!
open("./python_plugin.so"): No such file or directory [core/utils.c line 3347]
!!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!!
*** Starting uWSGI 1.9.8 (64bit) on [Sat Apr 27 06:29:18 2013] ***
compiled with version: 4.6.3 on 27 April 2013 00:06:22
os: Linux-3.2.0-36-virtual #57-Ubuntu SMP Tue Jan 8 22:04:49 UTC 2013
nodename: ip-10-245-51-230
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /usr/share/nginx/www/eztech
detected binary path: /usr/local/bin/uwsgi
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 4595
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address /usr/share/nginx/www/eztech/uwsgi.sock fd 3
setgid() to 33
setuid() to 33
Python version: 2.7.3 (default, Aug 1 2012, 05:25:23) [GCC 4.6.3]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x2505520
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72688 bytes (70 KB) for 1 cores
*** Operational MODE: single process ***
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 12800, cores: 1)
Thank you for any assistance you can offer!
As Blender already says, there should be no try_files where is your upstream called.
The following nginx config is enough to host flask application:
server {
listen 80;
server_name ezte.ch;
location / {
uwsgi_pass unix:/usr/share/nginx/www/eztech/uwsgi.sock;
include uwsgi_params;
}
}
my flask config:
<uwsgi>
<autostart>true</autostart>
<master/>
<pythonpath>/var/www/apps/someapp/</pythonpath>
<plugin>python</plugin>
<module>someapp:app</module>
<processes>4</processes>
</uwsgi>
So there is path /var/www/apps/someapp/ and flask file someapp.py
I had the same issue. just remove this line from the nginx configuration :
root /usr/share/nginx/www/eztech/public_html;

Resources