6

I'm trying to set up a chef recipe that will get my site running and everything seems to be working fine except for uWSGI which is giving me the following error:

*** has_emperor mode detected (fd: 6) ***
[uWSGI] getting INI configuration from app-cms.ini
removed uwsgi instance app-cms.ini

No longer say this:

open("/var/www/app-cms/logs/uwsgi.log"): Permission denied [utils.c line 246]

That log file is now being created and contains the following:

*** Starting uWSGI 1.0.3-debian (64bit) on [Thu Feb  6 12:00:43 2014] ***
compiled with version: 4.6.3 on 17 July 2012 02:26:54
current working directory: /etc/uwsgi/apps-enabled
writing pidfile to /var/www/ediflo-cms/run/ediflo-cms.pid
detected binary path: /usr/bin/uwsgi-core
setgid() to 33
setuid() to 33
chdir(): Permission denied [uwsgi.c line 1723]
chdir(): Permission denied [uwsgi.c line 975]

I'm not sure where it is trying to chdir() to.

I'm starting uWSGI in emperor mode and having it watch /etc/uwsgi/apps-enabled/ for ini files using the following upstart config file:

description "uWSGI"
start on runlevel [2345]
stop on runlevel [06]

respawn

exec uwsgi --emperor /etc/uwsgi/apps-enabled --uid uwsgi --gid www-data --logto /var/log/uwsgi/uwsgi.log

This is my uWSGI app config:

[uwsgi]
; define variables to use in this script
; process name for easy identification in top
project = app-cms
base_dir = /var/www/app-cms
chdir = %(base_dir)

pythonpath = %(base_dir)/env/bin

uid = www-data
gid = www-data

procname = %(project)

; This value needs to be tuned
workers = 4

; Create pid file for easier process management
pidfile = %(base_dir)/run/%(project).pid

; Specify your app here
module = %(project)-wsgi:application

log-reopen = true
logto = %(base_dir)/logs/uwsgi.log

chmod-socket = 660

vacuum = True
enable-threads = True

; unix socket
socket = /tmp/app-cms-server.sock
; Enable stats
stats = /tmp/app-cms-stats.sock

1 Answer 1

3

if the Emperor runs as unprivileged user, vassals cannot drop to a specific uid and gid and more important master-as-root does not make sense (it is generally a bad idea to use it, it is here only for embedded systems that need to access the hardware for specific features).

Check if a /var/www/app-cms/logs/uwsgi.log already exists and is owned by root, very probably it is the result of a previous attempt and now the unprivileged process cannot access it in write mode.

Finally, do not map Emperor and vassals to the same logfile, it is implicit as file descriptor 2 is inherited and it could lead to various problems if the vassal has different permissions from the Emperor (it is not your case)

2
  • So if I set the emperor as root and give it a specific log file it should work and get rid of the master stuff from the vassal? The log file doesn't exist at this point. I'll be able to try this shortly.
    – Nalum
    Feb 5, 2014 at 8:00
  • Updated question with new information from the user and group change.
    – Nalum
    Feb 6, 2014 at 11:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .