[Django] #26214: Better error message for RuntimeError: populate() isn't reentrant
Django
---------------------------------+-----------------
Reporter: guettli | Owner:
Type: Uncategorized | Status: new
Component: Error reporting | Version: 1.9
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+-----------------
We were hit by an exception like this in production environment
{{{
Traceback (most recent call last):
File "/home/foobar_fm_p/src/foobar-fm/foobar_fm/apache/django_wsgi.py",
line 4, in <module>
application = wsgi.get_handler()
File "/home/foobar_fm_p/src/djangotools/djangotools/utils/wsgi.py", line
54, in get_handler
return get_wsgi_application()
File "/home/foobar_fm_p/lib/python2.7/site-
packages/django/core/wsgi.py", line 14, in get_wsgi_application
django.setup()
File "/home/foobar_fm_p/lib/python2.7/site-packages/django/__init__.py",
line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File "/home/foobar_fm_p/lib/python2.7/site-
packages/django/apps/registry.py", line 78, in populate
raise RuntimeError("populate() isn't reentrant")
RuntimeError: populate() isn't reentrant
}}}
To debug this, I am missing an very important part:
The Stacktrace of the other one trying to load the config
Here is the code part
{{{
# app_config should be pristine, otherwise the code below
won't
# guarantee that the order matches the order in
INSTALLED_APPS.
if self.app_configs:
raise RuntimeError("populate() isn't reentrant")
}}}
My idea: the first one, who passes above check stores its current
stracktrace to a variable.
The if the second fails, and RuntimeError("populate() isn't reentrant")
gets executed, the exception can show the stacktrace of the first run.
With this you can debug it. Otherwise you are lost.
What do you think?
--
Ticket URL: <https://code.djangoproject.com/ticket/26214>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: guettli | Owner:
Type: Uncategorized | Status: new
Component: Error reporting | Version: 1.9
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by guettli):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
New description:
We were hit by an exception like this in production environment
{{{
Traceback (most recent call last):
File "foobar-fm/foobar_fm/apache/django_wsgi.py", line 4, in <module>
application = wsgi.get_handler()
File "djangotools/djangotools/utils/wsgi.py", line 54, in get_handler
return get_wsgi_application()
File "lib/python2.7/site-packages/django/core/wsgi.py", line 14, in
get_wsgi_application
django.setup()
File "lib/python2.7/site-packages/django/__init__.py", line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File "lib/python2.7/site-packages/django/apps/registry.py", line 78, in
populate
raise RuntimeError("populate() isn't reentrant")
RuntimeError: populate() isn't reentrant
}}}
To debug this, I am missing an very important part:
The Stacktrace of the other one trying to load the config
Here is the code part
{{{
# app_config should be pristine, otherwise the code below
won't
# guarantee that the order matches the order in
INSTALLED_APPS.
if self.app_configs:
raise RuntimeError("populate() isn't reentrant")
}}}
My idea: the first one, who passes above check stores its current
stracktrace to a variable.
The if the second fails, and RuntimeError("populate() isn't reentrant")
gets executed, the exception can show the stacktrace of the first run.
With this you can debug it. Otherwise you are lost.
What do you think?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:1>
Django
Reporter: guettli | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Core (Other) | Version: 1.9
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* owner: => nobody
* cc: aaugustin (added)
* component: Error reporting => Core (Other)
* type: Uncategorized => Cleanup/optimization
Comment:
I'm not sure. Aymeric, what's your opinion?
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:2>
Django
Reporter: guettli | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Core (Other) | Version: 1.9
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
I understand the reasoning behind this suggestion, but in my experience,
trying to be smart with error handling often backfires, and my gut feeling
is that this is too magical.
Besides Python 3's exception chaining solves the problem entirely... Let's
say that my motivation for doing something is non-existent, given that I
don't plan to ever use Python 2 again.
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:3>
Django
Reporter: guettli | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: 1.9
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => wontfix
Comment:
The rationale makes sense to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:4>
Django
Reporter: guettli | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Core (Other) | Version: 1.9
Severity: Normal | Resolution: wontfix
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by guettli):
> Python 3's exception chaining solves the problem entirely.
I only used Python2 up to now. I guess it is time to upgrade.
Thank you for your feedback.
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:5>
Django
Reporter: Thomas Güttler | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Core (Other) | Version: 1.9
Severity: Normal | Resolution: wontfix
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Thomas Güttler):
5 years later, running Python 3.8 I come across the same error again. On
the Python command line it works, there I see the real error:
`ModuleNotFoundError: No module named 'psycopg2'`
But if I run this via PyCharm "execute file". I get the meaningless error
message.
Here is an answer to see the real error message, if you don't see it:
https://stackoverflow.com/a/55929118/633961 (replace the exection in
registry.py with `self.app_configs = {}`)
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:6>
Django
Reporter: Thomas Güttler | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Core (Other) | Version: 1.9
Severity: Normal | Resolution: wontfix
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Adrian Torres):
Is there a way that we can reopen this ticket? It's still a constant issue
and debugging the actual root cause of the issue can prove to be
problematic in remote environments, the linked solution in StackOverflow
has over 100k views which just goes to show how many people have run into
this issue and still do.
Don't know why Aymeric mentions Python 3's exception chaining by default,
it clearly does not happen here, at least not when executing commands such
as `python3 manage.py migrate`.
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:7>
Django
Reporter: Thomas Güttler | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Core (Other) | Version: 1.9
Severity: Normal | Resolution: wontfix
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
If you can provide a patch with some concrete proposals that improves
things without regressions, I guess this could be reconsidered.
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:8>
Django
Reporter: Thomas Güttler | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Core (Other) | Version: 1.9
Severity: Normal | Resolution: wontfix
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Bruno Henrique de Paula):
Hey guys, is there a way to fix this? This is a well known issue in the
Python community, it's not practical to keep editing the registry.py file
and doing the workaround proposed here ->
https://stackoverflow.com/a/55929118/633961 in order to see the real
problem. How could we solve this?
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:9>
Django
Reporter: Thomas Güttler | Owner: nobody
Component: Core (Other) | Version: 1.9
Severity: Normal | Resolution:
| Unreviewed
Changes (by Aymeric Augustin):
* resolution: wontfix =>
* status: closed => new
Comment:
I wasn't aware that this could hide errors in settings. That's a problem
indeed.
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:10>
Django
Reporter: Thomas Güttler | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: dev
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Changes (by Natalia Bidart):
* resolution: => needsinfo
Comment:
I have read the StackOverflow post, but I'm still unclear on how to
reproduce this in a local development environment. I have tried running
Django with Gunicorn and forcing errors such as:
* An import error from the admin (no issues; I receive the traceback in
the console).
* An `ImproperlyConfigured` exception raised (no issues here either).
I will close this as `needsinfo` until someone can provide a small Django
project with instructions to reproduce this issue. Ideally, providing a
test case would also be helpful. In either case, please feel free to
reopen for us to re-triage. Thank you!
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:11>
Django
Reporter: Thomas Güttler | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Core (Other) | Version: dev
Severity: Normal | Resolution: needsinfo
| Unreviewed
Comment (by Aymeric Augustin):
Based on the StackOverflow question, it seemed as simple as "add invalid
code to settings", but indeed that's not enough. Thank you for double
checking. Hopefully someone who hits the problem will report back here
instead of on StackOverflow.
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:12>
Django
Reporter: Thomas Güttler | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Core (Other) | Version: dev
Severity: Normal | Resolution: needsinfo
| Unreviewed
Comment (by yzupnick):
I just hit this by installing django_allauth[socialaccount], and adding
these apps to the INSTALLED_APPS list, but without adding pyjwt,
cryptography, or requests to my python environment.
1. "allauth",
2. "allauth.account",
3. "allauth.socialaccount",
4. "allauth.socialaccount.providers.google"
(Also I am building using nix and dream2nix... not sure if that is causing
the problem...)
--
Ticket URL: <https://code.djangoproject.com/ticket/26214#comment:13>