Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Worker failed to boot #338
I have a reasonably straightforward Django site running in a virtualenv. It runs fine when i use ./manage.py runserver but when i try and run it with gunicorn i get the a Worker failed to boot error with no further explanation.
Where should i go looking to resolve this issue?
Actually I am having a similar issue and I think it is to do with write permissions on the log file. If I make the log files (stderr and stdout) publicly writeable it seems to be working fine. So I guess that brings me to the question of when you first start gunicorn from supervisord the log files are created under root before gunicorn takes over. What is the best way to manage ensure that log files are created by gunicorn and not by supervisord?
I launch it with supervisord. Here is my gunicorn config for supervisord:
And the actual gunicorn script (note how I touch and chown the log files to the gunicorn user/group):
user/group to run as
touch $ACCESS_LOGFILE $ERROR_LOGFILE $LOGFILE
export DATASTORE_SOFTWARE=$DATASTORE_SOFTWARE ; exec /opt/virtenvs/django_slice/bin/gunicorn_django $DEBUG_FLAGS -w $NUM_WORKERS --user=$USER --group=$GROUP --log-level=debug --log-file=$LOGFILE --access-logfile=$ACCESS_LOGFILE --error-logfile=$ERROR_LOGFILE
Good question about the latest head. pip freeze shows it to be 0.14.1 (.2 is latest isnt it?)
pushed a commit
May 14, 2012
I solved this problem too but in a different way. The first line of the gunicorn_django file was "#!/opt/django/env/mysite/bin/python", which is the path of my virtualenviroment python path. The problem solved by replace it as "#!/usr/bin/env python", although they both used the same python interpreter, but there are some PYTHONPATH difference, that's why it was failed before.
I encountered the same issue yesterday, with gunicorn 0.18 and the following invokation:
gunicorn 'app:create_app()' --name X --workers 5 --user=apprunner --group=apprunner --bind='0.0.0.0:5000' --log-config=resource/config/di/logging.conf --timeout=360 --debug --log-level debug
It was due to an ImportError in my Flask application. The takeway here is that gunicorn does not display the traceback from the application if the worker crashes at boot, so I had to start the Flask app manually to see the actual problem.
If I understand the problem correctly, Gunicorn already shows the exception messages like ImportError:
and other kind of error messages:
added a commit
Aug 20, 2015
referenced this issue
Sep 28, 2015
@brouberol I came across the same issue even now. When a Flask application has some module causing import error, Gunicorn won't log the traceback but Flask's built-in server can.
What we can do is that if Gunicorn failed to boot worker without more specific information in any error log, first try Flask's builtin server.