Impossible de démarrer Gunicorn via Supervisor après le redémarrage du server

J'ai une application Django "djngxgun" qui utilise Nginx et Gunicorn. Je viens d'installer Supervisor afin que je puisse l'utiliser pour gérer mes process Gunicorn. Le problème est que le superviseur ne démarre pas Gunicorn après le redémarrage du server. Lorsque je commence Gunicorn via Supervisor ("sudo supervisorctl start djngxgun"), je vois que l'erreur suivante est répétée dans mon file Gunicorn error.log:

2014-02-28 15:36:47 [4753] [INFO] Starting gunicorn 18.0 Traceback (most recent call last): File "/home/djngxgun/venv/djngxgun/bin/gunicorn", line 9, in <module> load_entry_point('gunicorn==18.0', 'console_scripts', 'gunicorn')() File "/home/djngxgun/venv/djngxgun/local/lib/python2.7/site-packages/gunicorn/app/wsgiapp.py", line 71, in run WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run() File "/home/djngxgun/venv/djngxgun/local/lib/python2.7/site-packages/gunicorn/app/base.py", line 143, in run Arbiter(self).run() File "/home/djngxgun/venv/djngxgun/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 172, in run self.start() File "/home/djngxgun/venv/djngxgun/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 124, in start self.pidfile.create(self.pid) File "/home/djngxgun/venv/djngxgun/local/lib/python2.7/site-packages/gunicorn/pidfile.py", line 38, in create fd, fname = tempfile.mkstemp(dir=fdir) File "/usr/lib/python2.7/tempfile.py", line 300, in mkstemp return _mkstemp_inner(dir, prefix, suffix, flags) File "/usr/lib/python2.7/tempfile.py", line 235, in _mkstemp_inner fd = _os.open(file, flags, 0600) OSError: [Errno 13] Permission denied: '/var/run/tmpcda84p' 

Il semble que le problème est que le count djngxgun doit créer un file temporaire dans / var / run, mais les permissions de ce directory l'empêchent:

 drwxr-xr-x 14 root root 640 Feb 28 15:36 /run 

Si je change / exécute manuellement (/ var / run est un lien symbolique vers / run) afin que le propriétaire du groupe soit "adm" et qu'il soit écrit en groupe et que djngxgun soit ajouté au groupe adm comme celui-ci,

 drwxrwxr-x 14 root adm 640 Feb 28 15:36 /run 

… Je peux commencer Gunicorn via Supervisor sans aucun problème. Cependant, si je redémarre mon server, la propriété du groupe et les permissions reviennent aux parameters d'origine qui provoquent l'échec de l'erreur. Comme vous vous attendez, si je lance simplement le script de démarrage à la main ("sudo / www / djngxgun / bin / start-gunicorn &"), Gunicorn démarre sans aucun problème.

Est-ce que je configure Gunicorn et / ou Supervisor de manière incorrecte? Je ne vois pas comment je peux m'avoir besoin d'écrire dans / var / run si j'utilise Supervisor mais je ne peux pas si c'est la propriété de root. Je ne pense pas que je souhaite exécuter ma request via l'user root. Je n'ai pas vu de parameters Gunicorn ou Supervisor qui résoudraient ce problème. Existe-t-il une autre façon de le faire?

Merci.

C'est mon script de démarrage de Gunicorn:

 #!/bin/bash NAME=djngxgun DJANGODIR=/www/djngxgun USER=$NAME GROUP=$NAME NUM_WORKERS=3 DJANGO_SETTINGS_MODULE=conf.prod DJANGO_WSGI_MODULE=conf.wsgi WORKON_HOME=/home/${USER}/venv source `which virtualenvwrapper.sh` workon $NAME export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE export PYTHONPATH=$DJANGODIR:$PYTHONPATH echo "Starting $NAME as `whoami`" exec gunicorn $DJANGO_WSGI_MODULE:application \ --name $NAME \ --workers $NUM_WORKERS \ --user=$USER \ --group=$GROUP \ --bind=127.0.0.1:8000 \ --pid /var/run/gunicorn.pid \ --access-logfile /var/log/gunicorn/access.log \ --error-logfile /var/log/gunicorn/error.log \ --log-level=debug 

C'est mon file de configuration de Supervisor "/etc/supervisor/conf.d/djngxgun.conf"

 [program:djngxgun] command = /www/djngxgun/bin/start-gunicorn user=djngxgun stdout_logfile = /var/log/gunicorn/supervisor.log redirect_stderr = true 

    Vous ne devez pas utiliser votre server Gunicorn en tant que root, il suffit de penser si quelqu'un a trouvé un exploit dans votre code peut tout faire sur le server.

    Mettez le pidfile dans / tmp ou / var / tmp et exécutez-vous en tant qu'user non privilégié.

    Je l'ai compris. La solution consiste à définir "user = root" dans le file de configuration Supervisor du projet. La documentation indique: "Si le controller s'exécute en tant que root, ce count d'user UNIX sera utilisé comme count qui exécute le programme". Ainsi, configurer l'user de cette façon équivaut à l'exécution manuelle du script à l'aide de "sudo".