简体   繁体   English

Nginx 错误:(13:权限被拒绝)同时连接到上游

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

I am getting this error in my nginx-error.log file:我在我的nginx-error.log文件中收到此错误:

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.浏览器还显示 502 Bad Gateway Error。 The output of a curl is the same, Bad Gateway html一个curl的curl是一样的,Bad Gateway html

I've tried to fix it by changing permissions for /tmp/uwsgi.sock to 777. That didn't work.我试图通过将/tmp/uwsgi.sock的权限更改为 777 来修复它。那没有用。 I also added myself to the www-data group (a couple questions that looked similar suggested that).我还将自己添加到www-data组(一些看起来相似的问题暗示了这一点)。 Also, no dice.此外,没有骰子。

Here is my nginx.conf file:这是我的nginx.conf文件:

nginx.conf 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.我正在使用 Nginsx 和 Uwsgi 运行 Flask 应用程序,只是为了在我的解释中彻底。 If anyone has any ideas, I would really appreciate them.如果有人有任何想法,我将不胜感激。


EDIT编辑

I have been asked to provide my uwsgi config file.我被要求提供我的 uwsgi 配置文件。 So, I never personally wrote my nginx or my uwsgi file.所以,我从来没有亲自写过我的 nginx 或我的 uwsgi 文件。 I followed the guide here which sets everything up using ansible-playbook.我按照这里的指南使用 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. nginx.conf文件是自动生成的,但/etc/uwsgi除了apps-enabledapps-available文件夹中的README文件外没有任何内容。 Do I need to create my own config file for uwsgi?我需要为 uwsgi 创建自己的配置文件吗? I was under the impression that ansible took care of all of those things.我的印象是 ansible 负责所有这些事情。

I believe that ansible-playbook figured out my uwsgi configuration since when I run this command我相信ansible-playbook自从我运行此命令以来就发现了我的 uwsgi 配置

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. 出现权限问题是因为uwsgi将/tmp/uwsgi.sock的所有权和权限重置为755,并且每次uwsgi启动时用户都会运行uwsgi。

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. 解决问题的正确方法是让uwsgi更改/tmp/uwsgi.sock的所有权和/或权限,以便nginx可以写入此套接字。 Therefore, there are three possible solutions. 因此,有三种可能的解决方案。

  1. Run uwsgi as the www-data user so that this user owns the socket file created by it. 将uwsgi作为www-data用户运行,以便该用户拥有由其创建的套接字文件。

     uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data 
  2. Change the ownership of the socket file so that www-data owns it. 更改套接字文件的所有权,以便www-data拥有它。

     uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data 
  3. Change the permissions of the socket file, so that www-data can write to it. 更改套接字文件的权限,以便www-data可以写入它。

     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. 我更喜欢第一种方法,因为它不会让uwsgi以root身份运行。

The first two commands need to be run as root user. 前两个命令需要以root用户身份运行。 The third command does not need to be run as root user. 第三个命令不需要以root用户身份运行。

The first command leaves uwsgi running as www-data user. 第一个命令使uwsgi作为www-data用户运行。 The second and third commands leave uwsgi running as the actual user that ran the command. 第二个和第三个命令使uwsgi作为运行命令的实际用户运行。

The first and second command allow only www-data user to write to the socket. 第一个和第二个命令只允许www-data用户写入套接字。 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 . 我更喜欢第一种方法,因为它不会让uwsgi以root用户身份运行,并且它不会使套接字文件成为可写的。

While the accepted solution is true there might also SELinux be blocking the access. 虽然接受的解决方案是正确的,但SELinux也可能阻止访问。 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! 如果它工作,那么SELinux是错误的 - 或者说正在按预期工作! To add the permissions needed to nginx do: 要添加nginx所需的权限,请执行以下操作:

  # 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: 之后将SELinux策略重置为强制执行:

sudo setenforce Enforcing

You have to set these permissions ( chmod / chown ) in uWSGI configuration. 您必须在uWSGI配置中设置这些权限( chmod / chown )。

It is the chmod-socket and the chown-socket . 它是chmod-socketchown-socket

http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-socket http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chown-socket http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-socket http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chown-socket

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. 我建议跟随使用virtualenv,uwsgi和nginx的Running flask非常简单和甜蜜的文档。

Must activate your environment if you run your project in virtualenv. 如果您在virtualenv中运行项目,则必须激活您的环境。

here is the yolo.py 这是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. 并在/ tmp /目录中创建uwsgi.sock文件并将其留空。 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." 正如@susanpal的回答所说:“许可问题的发生是因为uwsgi将/tmp/uwsgi.sock的所有权和权限重置为755,并且每次uwsgi启动时用户都会运行uwsgi。” it is correct. 它是正确的。

So you have to give permission to sock file whenever uwsgi starts. 所以你必须在uwsgi启动时给sock文件授予权限。 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. @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 在我的情况下,改变一些PHP权限做的伎俩

sudo chown user:group -R /run/php

I hope this helps someone. 我希望这可以帮助别人。

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:任何从 Google 来到这里并尝试在安装 nginx 后使用默认 Ubuntu 映像在 AWS 上运行 Flask 的人仍然无法弄清楚问题是什么:

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.默认情况下,Nginx 以用户“www-data”的身份运行,但最常见的来自 Digital Ocean 的 Flask WSGI 教程让您使用登录用户作为 systemd 服务文件。 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.如果您的 Flask/wsgi 用户是“ubuntu”,那么在 /etc/nginx/nginx.conf 中将 nginx 运行的用户从“www-data”(这是默认值)更改为“ubuntu”并且一切都会开始工作。 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.试图让 Flask 和 uwsgi 作为 www-data 运行并没有立即起作用,但是让 nginx 作为 ubuntu 运行就很好了,因为无论如何我用这个实例运行的都是 Flask。

Nginx connect to.sock failed (13:Permission denied) - 502 bad gateway 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.在 /etc/nginx/nginx.conf 文件的第一行更改用户名。

the default user is www-data and change it to root or your username默认用户是 www-data 并将其更改为 root 或您的用户名

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). 你应该为你的应用程序发布nginx和uwsgi配置文件(在/ etc / nginx / sites-enabled /和/ etc / uwsgi / - 或者你把它们放在哪里)。

Typically check that you have a line similar to the following one in your nginx app configuration: 通常检查您的nginx应用程序配置中是否有类似于以下行的行:

uwsgi_pass unix:///tmp/uwsgi.sock;

and the same socket name in your uwsgi config file: 和uwsgi配置文件中的相同套接字名称:

socket=/tmp/uwsgi.sock

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 (13:权限被拒绝)连接到上游时:[nginx] - (13: Permission denied) while connecting to upstream:[nginx] Nginx(13:权限被拒绝)同时连接到上游 - Nginx (13: Permission denied) while connecting to upstream nginx 错误:(13:权限被拒绝)同时连接到上游) - nginx error: (13: Permission denied) while connecting to upstream) 连接到上游时的CentOS 6.4 + Nginx + uwsgi +(13:权限被拒绝) - CentOS 6.4 + Nginx + uwsgi + (13: Permission denied) while connecting to upstream NGINX 和 Docker 中的 Gunicorn 中的权限错误:connect() 到 unix:/tmp/gunicorn.sock 连接到上游失败(13:权限被拒绝) - Permission Error in NGINX and Gunicorn in Docker: connect() to unix:/tmp/gunicorn.sock failed (13: Permission denied) while connecting to upstream wsgi nginx错误:连接到上游时权限被拒绝 - wsgi nginx error: permission denied while connecting to upstream Nginx在上游连接到Unicorn时拒绝了许可 - Nginx denied permission while connecting upstream to Unicorn Gunicorn Nginx连接到上游时被拒绝 - Gunicorn Nginx Permission denied while connecting to upstream 连接到上游时 Nginx、django、gunicorn、ubuntu 14.04(13:权限被拒绝) - Nginx, django, gunicorn, ubuntu 14.04 (13: Permission denied) while connecting to upstream Nginx 错误:(13:权限被拒绝)在 /var/cache/nginx/proxy_temp/ 上读取上游时 - Nginx error: (13: Permission denied) while reading upstream on /var/cache/nginx/proxy_temp/
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM