Trying to run django with gunicorn (Worker failed to boot)
Question: 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](http://stackoverflow.com/questions/24488891/gunicorn-errors-haltserver-
haltserver-worker-failed-to-boot-3-django) and I've tried [this
way](http://docs.gunicorn.org/en/latest/run.html?highlight=django#django),
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()
    


Answer: 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.

