uWSGI

Question

Estou tentando configurar uma receita de chef que fará meu site funcionar e tudo parece estar funcionando bem, exceto por uWSGI , que está me dando o seguinte erro:

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

Não diga mais isso:

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

Esse arquivo de log agora está sendo criado e contém o seguinte:

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

Não sei ao certo para onde está tentando chdir() .

Estou começando o uWSGI no modo imperador e vendo-o /etc/uwsgi/apps-enabled/ para ini arquivos usando o seguinte arquivo de configuração upstart:

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

Esta é a minha 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

    

Answer 1

se o Emperor for executado como usuário não privilegiado, os vassalos não podem cair para um uid e gid específicos e o master-as-root mais importante não faz sentido (geralmente é uma má idéia usá-lo, ele está aqui apenas para sistemas embarcados que precisam acessar o hardware para recursos específicos).

Verifique se um /var/www/app-cms/logs/uwsgi.log já existe e é de propriedade de root, muito provavelmente é o resultado de uma tentativa anterior e agora o processo unprivileged não pode acessá-lo no modo de gravação.

Por fim, não mapeie o Emperor e vassals para o mesmo arquivo de log, ele está implícito já que o descritor de arquivo 2 é herdado e pode levar a vários problemas se o vassal tiver permissões diferentes do Emperor (não é o seu caso)