TL;DR
This blog post will explain how to get full exception stack trace during the gunicorn start up issue. gunicorn is python native application server for running django application.
So you changed something in your django settings.py configuration, and gunicorn failed to start. In my case, I did not get full exception stack trace, which means I did not know what was the root cause for this issue.
Traceback (most recent call last):
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 196, in run
web_1 | self.sleep()
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 346, in sleep
web_1 | ready = select.select([self.PIPE[0]], [], [], 1.0)
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 231, in handle_chld
web_1 | self.reap_workers()
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 506, in reap_workers
web_1 | raise HaltServer(reason, self.WORKER_BOOT_ERROR)
web_1 | gunicorn.errors.HaltServer: <HaltServer 'Worker failed to boot.' 3>
web_1 |
web_1 | During handling of the above exception, another exception occurred:
web_1 |
web_1 | Traceback (most recent call last):
web_1 | File "/usr/local/bin/gunicorn", line 11, in <module>
web_1 | sys.exit(run())
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/app/wsgiapp.py", line 74, in run
web_1 | WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run()
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/app/base.py", line 192, in run
web_1 | super(Application, self).run()
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/app/base.py", line 72, in run
web_1 | Arbiter(self).run()
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 218, in run
web_1 | self.halt(reason=inst.reason, exit_status=inst.exit_status)
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 331, in halt
web_1 | self.stop()
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 381, in stop
web_1 | time.sleep(0.1)
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 231, in handle_chld
web_1 | self.reap_workers()
web_1 | File "/usr/local/lib/python3.4/site-packages/gunicorn/arbiter.py", line 506, in reap_workers
web_1 | raise HaltServer(reason, self.WORKER_BOOT_ERROR)
web_1 | gunicorn.errors.HaltServer: <HaltServer 'Worker failed to boot.' 3>
Google led me to this usefull blog post.
gunicorn slweb.wsgi:application --preload
And official gunicorn documentation explains –preload option:
Load application code before the worker processes are forked.
Because first exception describes worker spawn failure, loading application before worker spawn may trigger more detailed exception.
And that was true:
django.core.exceptions.ImproperlyConfigured: 'oracle' isn't an available database backend.
Try using 'django.db.backends.XXX', where XXX is one of: 'base', 'mysql', 'oracle', 'postgresql_psycopg2', 'sqlite3'
The root cause was wrong name for oracle driver.
