New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Worker failed to boot #338
Comments
Is gunicorn installed inside the virtualenv or outside? |
inside. by now i think it's an app issue since gunicorn starts when i throw out most of the settings, it's just that you can't tell what's failing when looking at that output. |
Try with "--debug --log-level debug". See if you get any more info. |
this is the output with the debug log level i'm afraid |
😞 |
Thanks man, if i figure it out myself i'll let you know. i'm now working through the settings.py turning stuff on until i hit the error again. Old school debugging :) |
@benoitc why did |
I generally don't like to use that one since this is just a python thing if that makes sense. Debug sound more appropriate there. The real addition there is the traceback :) |
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? |
How do you launch gunicorn? Do you reproduce it with last head ? |
I launch it with supervisord. Here is my gunicorn config for supervisord: [program:sliceweb] And the actual gunicorn script (note how I touch and chown the log files to the gunicorn user/group): #!/bin/bash set -e user/group to run asUSER=www-data 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?) |
Have u solve the problem? I have the same issue and currently I have no idea how to solve this. |
It should be solved yes. Which version of gunicorn are you running? Can you provide me more information about your config so I can reproduce it? Thanks. @panyam did you tried with 0.14.3 ? |
@benoitc Sorry mate I didnt try it on 0.14.3. I managed to get it working on 0.14.1 by making the gunicorn user the owner of the log files as soon as supervisord starts the script. |
Just to clarify I dont think this is a gunicorn issue. @anyeguyue - the best place to check this would be to look the supervisord log or the gunicorn log (usually in /var/log/gunicorn/....) to see if you have a "permission denied" error in there. |
I just got the same issue, solved by first 'python manage.py syncdb' which led to an error. After fixing that setting issue, gunicorn worked (after restarting nginx). |
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. |
@anyeguyue I faced the same problem on gunicorn 0.14.5 and Django 1.4, but with even worse symptoms: |
@asimihsan, glad to help |
I also had this issue. Came out it was some problem with wrong imports in my code. If you want to debug try running gunicorn_django --preload - this will hopefully spit out the right exception. |
For anyone facing the same issue, the problem is usually something in django itself. This will usually give you a more detailed error message. |
👍 @fergalmoran Helped me solve my problem (it was a problem with PIL) |
I'm facing the same problem... and don't know how to solve it |
@pythdasch there have been a couple different problems talked about here. If you can provide some more information please open a new ticket, or simply send a message to the mailing list and others might be able to help you debug. |
I think we solved @pythdasch's problem on #gunicorn. @pythdasch, can you confirm? |
I confirm, thanks to berker :) My wsgi was in the same folder as my manage.py so I had to put path wsgi:application and not project.wsgi:application |
(It was the wrong path to wsgi. In this case needed to be wsgi:application instead of project.wsgi:application) |
@tilgovi yes sorry I went to the irc channel gunicorn to solve it :) |
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. |
I wonder if we could get it to display the actual traceback |
This would be very nice. IMO, the next best thing, if displaying the original traceback is not possible, would to to include a message suggesting to run the application directly, instead of using gunicorn, to look for the actual error. |
If I understand the problem correctly, Gunicorn already shows the exception messages like ImportError:
and other kind of error messages:
|
I faced the same issue when I tried to run the app like this:
The problem had been the presence of a directory named |
@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. |
run guncorn with --preload can see the error log |
For me, Django |
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?
The text was updated successfully, but these errors were encountered: