2

I have been trying to deploy django using nginx and gunicorn, currently running into an issue right off the bat, I followed the advice suggested on SO and I've tried this way, suggested in gunicorn docs But still has not worked...

(env)nathann@localhost:~/ipals$ ls -l
total 12
drwxrwxr-x 14 nathann nathann 4096 Aug 21 17:32 apps
-rw-rw-r--  1 nathann nathann 1590 Aug 21 17:55 ipals_wsgi.py
-rw-rw-r--  1 nathann nathann 1091 Aug 21 17:32 README.md
(env)nathann@localhost:~/ipals$ gunicorn ipals:application -b 127.0.0.1:8001
Traceback (most recent call last):
  File "/home/nathann/env/bin/gunicorn", line 11, in <module>
    sys.exit(run())
  File "/home/nathann/env/local/lib/python2.7/site-packages/gunicorn/app/wsgiapp.py", line 74, in run
    WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run()
  File "/home/nathann/env/local/lib/python2.7/site-packages/gunicorn/app/base.py", line 185, in run
    super(Application, self).run()
  File "/home/nathann/env/local/lib/python2.7/site-packages/gunicorn/app/base.py", line 71, in run
    Arbiter(self).run()
  File "/home/nathann/env/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 169, in run
    self.manage_workers()
  File "/home/nathann/env/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 477, in manage_workers
    self.spawn_workers()
  File "/home/nathann/env/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 542, in spawn_workers
    time.sleep(0.1 * random.random())
  File "/home/nathann/env/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 209, in handle_chld
    self.reap_workers()
  File "/home/nathann/env/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 459, in reap_workers
    raise HaltServer(reason, self.WORKER_BOOT_ERROR)
gunicorn.errors.HaltServer: <HaltServer 'Worker failed to boot.' 3>

And here is the contents of ipals_wsgi.py

import sys
import os
import os.path

# assume we(this file) exist as a sibling to the CODE_DIR
OUR_DIR = os.path.abspath(os.path.dirname(__file__))

# apps dir is our sibling. That's where our apps are.
APPS_DIR = os.path.join(OUR_DIR, 'apps')

# env dir is also a sibling to us and ipals
ENV_DIR = os.path.join(OUR_DIR, '../env')

# activate the virtualenv
activate_this = os.path.join(ENV_DIR, 'bin', 'activate_this.py')
execfile(activate_this, dict(__file__=activate_this))


# add the apps directory to the python path
sys.path.insert(0, APPS_DIR)


# load up django
# from django.core.management import execute_manager
from django.core.handlers.wsgi import WSGIHandler

# tell django to find settings at APPS_DIR/mainsite/settings.py'
#os.environ['DJANGO_SETTINGS_MODULE'] = 'ipals.settings_production'
os.environ['DJANGO_SETTINGS_MODULE'] = 'ipals.settings'

# hand off to the wsgi application
application = WSGIHandler()
Community
  • 1
  • 1
broinjc
  • 2,619
  • 4
  • 28
  • 44

1 Answers1

0

I'm not sure why you've got a file called ipals_wsgi.py, and that it appears to be in the top level of the project, or where your settings file is. Usually Django's startproject command creates a subdirectory with the same name as the project, and puts a file called wsgi.py alongside settings.py in that subdirectory. You seem to have modified that, but I can't understand why.

In any case, the fact that your wsgi file is called that points to what the problem is: you are telling gunicorn to look in a file called ipals, but as noted the file is called ipals_wsgi. Either rename the file or change the command: but even more preferable, revert to Django's default app layout - I suspect that even once you have fixed the current issue, you will encounter problems with the settings not being found, which wouldn't happen with the default.

Daniel Roseman
  • 588,541
  • 66
  • 880
  • 895
  • So, I've tried different things, but gunicorn still fails. Here's my directory structure and `wsgi.py` and `ipals_wsgi.py` https://gist.github.com/broinjc/0bc71688a5fa44ef2bee – broinjc Aug 21 '14 at 19:31
  • He appears to be working against older Django API so may be upgrading from older Django version from before wsgi.py was generated. Or more likely, hasn't bothered to follow official documentation and is following some random persons blog post about how to set it up. – Graham Dumpleton Aug 22 '14 at 02:42