Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a Django application "djngxgun" that uses Nginx and Gunicorn. I just installed Supervisor so that I can use it to manage my Gunicorn processes. The problem is that Supervisor isn't starting Gunicorn after I reboot the server. When I start Gunicorn via Supervisor ("sudo supervisorctl start djngxgun"), I see the following error repeated in my Gunicorn error.log file:

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'

It looks like the problem is that the djngxgun account needs to create a temporary file in /var/run but that directory's permissions are preventing it:

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

If I manually change /run (/var/run is a symlink to /run) so that it's group owner is "adm" and it's group-writable and djngxgun is added to the adm group like this,

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

... I can start Gunicorn via Supervisor without any problem. However, if I reboot my server, the group ownership and permissions revert back to the original settings which causes the error to reoccur. As you would expect, if I just run the startup script by hand ("sudo /www/djngxgun/bin/start-gunicorn &"), Gunicorn starts without any problem.

Am I configuring Gunicorn and/or Supervisor incorrectly? I don't see how I can get around needing to write to /var/run if I use Supervisor but I can't if it's owned by root. I don't think I want to be running my application via the root user. I didn't see any Gunicorn or Supervisor settings that would resolve this issue. Is there another way to do this?

Thanks.

This is my Gunicorn startup script:

#!/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

This is my Supervisor config file "/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
share|improve this question
add comment

2 Answers 2

You shouldn't be running your gunicorn server as root, just think if someone found an exploit in your code can do anything to the server.

Put the pidfile in /tmp or /var/tmp and run as a non privileged user.

share|improve this answer
add comment
up vote 0 down vote accepted

I figured it out. The solution is to set "user = root" in the project's Supervisor configuration file. The documentation says, "If supervisord runs as root, this UNIX user account will be used as the account which runs the program." Thus, setting user this way is equivalent to my running the script manually using "sudo."

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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