-
Notifications
You must be signed in to change notification settings - Fork 68
Incompatibilty with gunicorn. #3
Comments
Hi Alexander, Sorry about that, I'll look into this as soon as I can. The strange thing is the recent change was to prevent the stacktrace that you pasted which was occurring to the user who made the pull request, whereby now it shouldn't reach the thread.start() more than once if the thread is already started. Thanks for the details about your stack. I'll keep you updated on here |
No worries. This was the change that caused the problem, interesting that it should fix in one and break in another setup. |
This commit has introduced a similar problem (it isn't gunicorn related, but we get the same |
@AJamesPhillips , @Marklc , I just obtained some more information about our particular problem here: We use the Celery distributed task scheduler, and if we start our Celery workers with the option FORCE_EXECV=True, then we do not get this error. If we do not pass the option (the default is False), we get this error. Something about the Celery threading and Logentries threading doesn't play well together, evidently... |
We are getting this error when running Celery + New Relic + Logentries.
|
Can you try the latest version ? https://pypi.python.org/pypi/Logentries |
Error is reproducible when running workers using Celery.
|
Seeing the same issue with Logentries==0.7, Django==1.4.20, django-celery==3.1.10: Traceback (most recent call last): |
same issue with logentries 0.7 and flask |
Same here with logentries 0.8 + aiohttp + gunicorn |
To solve this issue I had to make a except RuntimeError: # It's already started.
- if not self._thread.is_alive():
- raise
+ pass |
Likewise here, just using |
Same problem with multiple processes in python. |
Does not happen if we don't use logging in the parent process. |
We had the same issue using 0.15. Problem was that we called:
after calling the Logentries handler. Interestingly, it didn't happen on the dev machine, but it did in a cloud env. Not sure why. |
Maybe the PR #46 solve this issue |
We have a web app using django and gunicorn, I don't appreciate how gunicorn handles its workers but after the recent changes we're getting:
If there's any further information I can provide that might help please let me know, also apologies if this is not an issue for le_python, however when we moved to commit
1726b2271b0fa6d9da4332e165f4ae394e4ffd47
it seems to have resolved the problem. We're using gunicorn 18.0, python 2.7, ubuntu, and we're monkey patching gunicorn.from gevent import monkey; monkey.patch_all(subprocess=False)
The text was updated successfully, but these errors were encountered: