I am building an app using an Nginx, uWSGI, Django and Postgresql stack. The app uses a Unix socket between Nginx and uWSGI. The file permissions on the socket is 775. But I still get this permission error:

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

Nginx Configuration

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

# redirect www to non-www
    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;

The files in my virtual environment have all been chown to ubuntu:ubuntu. The nginx user is ubuntu.

uWSGI log

*** 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)

Can someone please tell me what is causing this permissions problem?

  • First thing to check is that the application is listening. If it's listening on a network socket you just curl it, but I don't know how to check a Unix socket. – Tim Apr 17 '16 at 19:22

It looks like uWSGI service is listening on a Unix socket w/different absolute path (due to chdir() call). You can use lsof | grep "/path/to/socket" to find an absolute path of a Unix socket being listened on. I guess it is /path/to/chdir/path/to/socket.


I was able to fix the problem myself. I rebooted the server. Then I restarted Nginx and uWSGI with

sudo service nginx restart 
sudo service uwsgi restart

Nginx restarted without a problem. However, uWSGI returned this error:

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

I tried to switch to the directory. However, it didn't exist. So, I created the init directory in the uwsgi directory with:

sudo mkdir init

then I entered the new directory:

cd init

In that directory, I created the file that uWSGI could not find: do_command.

sudo nano do_command

With the file editor opened, I pasted this file that I found: https://raw.githubusercontent.com/jbq/uwsgi/master/debian/uwsgi-files/init/do_command:

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

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

  local COMMAND="$1"

  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"
        do_with_given_specific_daemon "$COMMAND" "$CONFSPEC_RELPATH"
        ERRORS="$(expr "$ERRORS" + "$?")"

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

    return "$ERRORS"

  # 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


  # 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\0/etc/uwsgi/apps-enabled/dir/site2.ini'
  # is transformed by sed into 'apps-enabled/site\0apps-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 "->"
    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}/:\1:g" \
                  -e "s:\([^\x0/]\+\)\([^\x0]\+\)\?/\([^/\x0]\+\)\.${UWSGI_CONFFILE_TYPES_REGEXP}\x0:\1/\3\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

  return "$ERRORS"

  local COMMAND="$1"

  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" ;;
  case "$?" in
    0) log_progress_ok "$RELATIVE_CONFPATH" ;;
    1) log_progress_skip "$RELATIVE_CONFPATH" ;;
    *) log_progress_error "$RELATIVE_CONFPATH"

  return "$ERRORS"

# Print progress notification about successful command execution.
  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"
    log_progress_msg '.'

# 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.
  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})"
    log_progress_msg "."

# Print progress notification about missing configuration file with given
# name.
  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}?"

# Print progress notification about failed command execution.
  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}!"

  log_progress_msg "done"

  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.
  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 '[\001-\037\177]' '?')"
  case "$CONFNAME" in
    *[[:space:]]*) echo "'$CONFNAME'" ;;
    *)             echo "$CONFNAME"   ;;

Then I restarted uWSGI:

sudo service uwsgi restart

The Django app launched normally.


1st of all, make the configuration easier to read and forget the upstream stuff. I am working for a longer time with uWSGI. I oftern had problems with the socket stuff (specially on python projects), but with PHP and uWSGI I get with sockets, suprisingly well.

If you REALLY persist to make use of uWSGI you need 2 things!

1st a config.ini where all uWSGI parameters related to your projects are stored, and the nginx configuration.

2nd the nginx.conf where the requests are routed back to uWSGI for further processing.

/etc/hosts: projekte.local


server {

   server_name projekte.local;
   include uwsgi_params;

   location / {

projekte.conf (our ini file):

socket =    
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

you change to the uWSGI application folder and start uWSGI with:

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

start nginx:


and open the url (this case: http://projekte.local)

Question: Why do you persist of using uWSGI ? gunicorn is for a standalone machine good enough, and much more simplier to use. to switch from gunicorn to uWSGI is done in one minute (without changing a single line of code).

uWSGI is for scaling... for standalone... hmmmm I don't know.

best, Tamer

  • Thanks. I was able to sort it out. I want to use uWSGI because I plan on using the machine instance for multiple projects. I would like to be able to scale if traffic picks up. The goal is to have it and not need, as opposed to need it and not have it. I like being prepared. Cheers. – user2901792 Apr 24 '16 at 4:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.