Nginx: 502 Erro de gateway incorreto com (111: Conexão recusada) para o soquete uWSGI durante a execução do django

2

Estou criando um aplicativo usando uma pilha Nginx, uWSGI, Django e Postgresql. O aplicativo usa um soquete Unix entre Nginx e uWSGI. As permissões de arquivo no soquete são 775. Mas ainda recebo esse erro de permissão:

[error] 6978#0: *6725 connect() to unix:/path/to/socket failed (111: Connection refused) while connecting to upstream, client: 54.250.253.225, server: example.com, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/path/to/socket:", host: "example.com"

Configuração Nginx

# uWSGI upstream
upstream app{
    server  unix:/path/to/socket;
    }

# redirect www to non-www
server{
    listen  80;
    server_name www.example.com;
    return  301 http://example.com$request_uri;
}

# configuration of the server
server {
    # the port your site will be served on
    listen      80;
    # the domain name it will serve for

    # substitute your machine's IP address or FQDN
    server_name example.com
    charset     utf-8;

    # root folder
    root    /path/to/root;

    # max upload size
    client_max_body_size 20M;   # adjust to taste

    access_log  /path/to/access.log;
    error_log   /path/to/error.log;

    # Django media
    location /media  {
    # your Django project's media files - amend as required
    alias /path/to/media;  
    }

    location /static {
    # your Django project's static files - amend as required
    alias /path/to/static; 
    }

    # Finally, send all non-media requests to the Django server.
    location / {
        uwsgi_pass  app;
    # the uwsgi_params file you installed
    include     /path/to/uwsgi_params; 

    uwsgi_param Host $host;
    uwsgi_param X-Real-IP $remote_addr;
    uwsgi_param UWSGI_SCHEME $scheme;
    uwsgi_param SERVER_SOFTWARE nginx/nginx_version;
    }
}

Os arquivos no meu ambiente virtual foram chown para o ubuntu: ubuntu. O usuário do nginx é o Ubuntu.

log do uWSGI

*** Starting uWSGI 2.0.12 (64bit) on [Sun Apr 17 17:24:37 2016] ***
compiled with version: 4.8.4 on 17 April 2016 14:40:25
os: Linux-3.13.0-85-generic #129-Ubuntu SMP Thu Mar 17 20:50:15 UTC 2016
nodename: ip-10-167-29-5
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /path/to/app
detected binary path: /path/to/bin/uwsgi
chdir() to /path/to/chdir
your processes number limit is 30035
your memory page size is 4096 bytes
 *** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers *** 
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 /path/to/socket fd 3
Python version: 3.4.3 (default, Oct 14 2015, 20:31:36)  [GCC 4.8.4]
Set PythonHome to /path/to/home
Python main interpreter initialized at 0xa4df10
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 436608 bytes (426 KB) for 5 cores
*** Operational MODE: preforking ***
/path/to/lib/python3.4/site-packages/cloudinary/models.py:24: RemovedInDjango110Warning: SubfieldBase has been deprecated. Use Field.from_db_value instead.
  return meta(name, bases, d)

WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0xa4df10 pid: 8567 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 8567)
spawned uWSGI worker 1 (pid: 8569, cores: 1)
spawned uWSGI worker 2 (pid: 8570, cores: 1)
spawned uWSGI worker 3 (pid: 8571, cores: 1)
spawned uWSGI worker 4 (pid: 8572, cores: 1)
spawned uWSGI worker 5 (pid: 8573, cores: 1)

Alguém pode me dizer o que está causando esse problema de permissão?

    
por user2901792 17.04.2016 / 19:28

3 respostas

0

Consegui resolver o problema sozinho. Eu reiniciei o servidor. Então eu reiniciei o Nginx e o uWSGI com

sudo service nginx restart 
sudo service uwsgi restart

O Nginx reiniciou sem problemas. No entanto, o uWSGI retornou esse erro:

/etc/init.d/uwsgi: line 73: /usr/share/uwsgi/init/do_command: No such file or directory

Eu tentei mudar para o diretório. No entanto, não existia. Então, eu criei o diretório init no diretório uwsgi com:

sudo mkdir init

então eu entrei no novo diretório:

cd init

Nesse diretório, criei o arquivo que o uWSGI não conseguiu encontrar: do_command.

sudo nano do_command

Com o editor de arquivos aberto, colei este arquivo que encontrei: link :

# This is shell script, sourced by uWSGI init.d script

. /usr/share/uwsgi/init/snippets
. /usr/share/uwsgi/init/specific_daemon

do_command()
{
  local COMMAND="$1"
  shift

  local ERRORS=0

  # If command is given with arguments, i.e. 'start smth smth_else'
  if [ -n "$1" ]; then
    [ "x$VERBOSE" != "xno" ] && log_progress_msg "->"

    # Iterate over given configuration file specifications and:
    # * either print notice that conforming conffile wasn't found (if it
    #   wasn't)
    # * or execute given command with conforming conffile
    local CONFSPEC_PATH=""
    for CONFSPEC in "$@"; do
      CONFSPEC_RELPATH="$(relative_path_to_conffile_with_spec "$CONFSPEC")"
      if [ -z "${CONFSPEC_RELPATH}" ]; then
        log_progress_not_found "$CONFSPEC"
      else
        do_with_given_specific_daemon "$COMMAND" "$CONFSPEC_RELPATH"
        ERRORS="$(expr "$ERRORS" + "$?")"
      fi
    done

    [ "$ERRORS" -eq 0 ] && log_progress_done

    return "$ERRORS"
  fi

  # Do not start daemon if it was disabled.
  if [ "x$COMMAND" = "xstart" -a "x$RUN_AT_STARTUP" != "xyes" ]; then
    [ "x$VERBOSE" != "xno" ] && log_progress_msg "(disabled; see /etc/default/${NAME})"
    return 2
  fi

  local SOME_CONF_WAS_FOUND=no
  local UWSGI_APPS_CONFDIRS="$(ls -1d ${UWSGI_APPS_CONFDIR_GLOB})"

  # This construction is needed for supporting configuration file names with
  # spaces or control characters.
  #
  # See http://www.dwheeler.com/essays/filenames-in-shell.html (paragraph #4).
  #
  # Predefined delimeters are resetted to null character (by changing IFS and
  # setting -d option of 'read' command) and then:
  # * 'find -print0' command is used for finding all available confnames
  # * 'while ... read' loop is used for iterating over found confnames
  # 
  # Also process substitution is used, so that variables changed inside 'while'
  # loop will retain their values after exiting from loop.
  #
  # By default 'find' command use emacs-style regexps. Emacs-style regexp
  # processor with given regexp doesn't matches to file names with newline
  # character. Posix-style regexp processor is working good.
  #
  # With executing 'sed' over found paths, relative configuration file
  # paths are extracted from full paths provided with 'find' output.
  # Firstly, common directory path (UWSGI_CONFDIR) is stripped from 'find'
  # output. Secondly, all directories (except the first) and file extensions
  # are stripped from result of first substitution.
  #
  # For example: list of found paths
  # '/etc/uwsgi/apps-enabled/site.ini
sudo service uwsgi restart
/etc/uwsgi/apps-enabled/dir/site2.ini' # is transformed by sed into 'apps-enabled/site
sudo service nginx restart 
sudo service uwsgi restart
apps-enabled/site2'. while IFS="" read -r -d "" RELATIVE_CONFPATH <&4 ; do if [ "x$SOME_CONF_WAS_FOUND" = "xno" -a "x$VERBOSE" != "xno" ]; then log_progress_msg "->" fi SOME_CONF_WAS_FOUND=yes do_with_given_specific_daemon "$COMMAND" "$RELATIVE_CONFPATH" ERRORS="$(expr "$ERRORS" + "$?")" done 4< <(find "$UWSGI_APPS_CONFDIRS" \ -regextype posix-basic \ -iregex ".*\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \ -print0 \ | sed -e "s:\(^\|\x0\)${UWSGI_CONFDIR}/::g" \ -e "s:\([^\x0/]\+\)\([^\x0]\+\)\?/\([^/\x0]\+\)\.${UWSGI_CONFFILE_TYPES_REGEXP}\x0:/\x0:g" \ | sort --zero-terminated --unique \ ) if [ "x$VERBOSE" != "xno" ]; then if [ "x$SOME_CONF_WAS_FOUND" = "xno" ]; then log_progress_msg "(omitted; missing conffile(s) in ${UWSGI_APPS_CONFDIR_GLOB})" elif [ "$ERRORS" -eq 0 ]; then log_progress_done fi fi return "$ERRORS" } do_with_given_specific_daemon() { local COMMAND="$1" shift local RELATIVE_CONFPATH="$@" local ERRORS=0 case "$COMMAND" in start) do_start_specific_daemon "$RELATIVE_CONFPATH" ;; stop) do_stop_specific_daemon "$RELATIVE_CONFPATH" ;; force-reload) do_force_reload_specific_daemon "$RELATIVE_CONFPATH" ;; reload|*) do_reload_specific_daemon "$RELATIVE_CONFPATH" ;; esac case "$?" in 0) log_progress_ok "$RELATIVE_CONFPATH" ;; 1) log_progress_skip "$RELATIVE_CONFPATH" ;; *) log_progress_error "$RELATIVE_CONFPATH" ERRORS=1 ;; esac return "$ERRORS" } # Print progress notification about successful command execution. log_progress_ok() { local RELATIVE_CONFPATH="$@" local CONFNAME="" [ "x$VERBOSE" = "xno" ] && return if [ "x$PRINT_CONFNAMES_IN_INITD_SCRIPT_OUTPUT" != "xno" ]; then CONFNAME="$(make_confname_for_progress_log "$RELATIVE_CONFPATH")" log_progress_msg "$CONFNAME" else log_progress_msg '.' fi } # Print progress notification about skipped command execution. # # It is printed, for example, when 'start' command was issued, but specific # daemon is already started. Or when 'stop' command was issued, but specific # daemon isn't runned yet. log_progress_skip() { local RELATIVE_CONFPATH="$@" local CONFNAME="" [ "x$VERBOSE" = "xno" ] && return if [ "x$PRINT_CONFNAMES_IN_INITD_SCRIPT_OUTPUT" != "xno" ]; then CONFNAME="$(make_confname_for_progress_log "$RELATIVE_CONFPATH")" log_progress_msg "(${CONFNAME})" else log_progress_msg "." fi } # Print progress notification about missing configuration file with given # name. log_progress_not_found() { local RELATIVE_CONFPATH="$@" local CONFNAME="" [ "x$VERBOSE" = "xno" ] && return if [ "x$PRINT_CONFNAMES_IN_INITD_SCRIPT_OUTPUT" != "xno" ]; then CONFNAME="$(make_confname_for_progress_log "$RELATIVE_CONFPATH")" fi log_progress_msg "${CONFNAME}?" } # Print progress notification about failed command execution. log_progress_error() { local RELATIVE_CONFPATH="$@" local CONFNAME="" [ "x$VERBOSE" = "xno" ] && return if [ "x$PRINT_CONFNAMES_IN_INITD_SCRIPT_OUTPUT" != "xno" ]; then CONFNAME="$(make_confname_for_progress_log "$RELATIVE_CONFPATH")" fi log_progress_msg "${CONFNAME}!" } log_progress_done() { log_progress_msg "done" } make_confname_for_progress_log() { local RELATIVE_CONFPATH="$@" local CONFNAMESPACE="$(extract_confnamespace "$RELATIVE_CONFPATH")" local CONFNAME="$(extract_confname "$RELATIVE_CONFPATH")" echo "$(sanitize_confname "${CONFNAMESPACE}/${CONFNAME}")" } # Sanitize configuration file name for printing it in terminal. sanitize_confname() { local CONFNAME="$@" # In sanitizing: # * all control ASCII characters are replaced with '?' character # * confname with spaces is surrounded by single quotes. CONFNAME="$(echo -n "$CONFNAME" | tr '[
/etc/init.d/uwsgi: line 73: /usr/share/uwsgi/init/do_command: No such file or directory
1-77]' '?')" case "$CONFNAME" in *[[:space:]]*) echo "'$CONFNAME'" ;; *) echo "$CONFNAME" ;; esac }

Então eu reiniciei o uWSGI:

sudo mkdir init

O aplicativo Django foi lançado normalmente.

    
por 18.04.2016 / 15:57
0

Parece que o serviço uWSGI está escutando em um soquete Unix com caminho absoluto diferente (devido a chdir() call). Você pode usar lsof | grep "/path/to/socket" para encontrar um caminho absoluto de um soquete Unix sendo ouvido. Eu acho que é /path/to/chdir/path/to/socket .

    
por 18.04.2016 / 00:21
0

Em primeiro lugar, torne a configuração mais fácil de ler e esquecer o material do upstream. Estou trabalhando por mais tempo com o uWSGI. Eu oftern tinha problemas com o material de soquete (especialmente em projetos python), mas com PHP e uWSGI eu fico com soquetes, surpreendentemente bem.

Se você realmente persistir em usar o uWSGI, precisará de 2 coisas!

Primeiro um config.ini onde todos os parâmetros do uWSGI relacionados aos seus projetos são armazenados e a configuração do nginx.

2º o nginx.conf onde as solicitações são roteadas de volta para o uWSGI para processamento adicional.

/ etc / hosts:

127.0.0.1 projekte.local

nginx.conf:

server {
   listen 127.0.0.1:80;

   server_name projekte.local;
   include uwsgi_params;

   location / {
     uwsgi_pass 127.0.0.1:3030;
   }

projekte.conf (nosso arquivo ini):

[uwsgi]
socket = 127.0.0.1:3030    
uid = daemon
gid = daemon

venv = /storage/PyENV/projekteENV
project_dir = /storage/PyProjects/bprojekte/projekte
chdir = %(project_dir)
master = true
plugins = plugins/python/python    

check-static = %(project_dir)
static-skip-ext = .py
static-skip-ext = .pyc
static-skip-ext = .inc
static-skip-ext = .tpl

pidfile2 = /var/run/uwsgi/projekte.pid
disable-logging = false
processes = 8
cheaper = 2
#daemonize2 = true

enable-threads = true
offload-threads = N
py-autoreload = 1
wsgi-file = /storage/PyProjects/bprojekte/projekte/wsgi.py

você muda para a pasta do aplicativo uWSGI e inicia o uWSGI com:

./uwsgi --ini /path/to/projekte.conf

inicie o nginx:

/usr/local/nginx/sbin/nginx

e abra o URL (neste caso: link )

Pergunta: Por que você persiste em usar o uWSGI? O gunicorn é para uma máquina autônoma suficientemente boa e muito mais simples de usar. alternar de gunicorn para uWSGI é feito em um minuto (sem alterar uma única linha de código).

uWSGI é para escalar ... para autônomo ... hmmmm eu não sei.

melhor, domador

    
por 19.04.2016 / 01:05