#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
--------------------------------------+------------------------------------
Reporter: kalium99 | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Core (Other) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by grahamd):
FWIW. The workaround for mod_wsgi is to do:
{{{
# Should only really do this in mod_wsgi daemon mode.
try:
application = get_wsgi_application()
except Exception:
time.sleep(0.25)
os.kill(os.getpid(), signal.SIGINT)
}}}
This is only of use though for transient errors such as a database not
being available. If the code is broken, then killing the process and
restarting it isn't going to help as the code is still going to be broken.
This issue of state full failure on loading an application also affects
other WSGI servers besides mod_wsgi but in other ways depending on the
mode they run in.
From memory uWSGI has some option one can set which will force process
restart after a number of successive failures to load a WSGI script
file/module, when it is in a mode where it does deferred loading. Other
WSGI servers may simply crash on startup and so if not using something
like supervisord will stay dead and not be restarted automatically.
I am looking at what is best solution for Apache/mod_wsgi, but I have to
look at some problems with signal handling during WSGI script file
preloading at the same time. I just haven't had the time to look at it
properly. I can only really implement a solution for mod_wsgi daemon mode
though where I control process existence. In the case of embedded mode
where Apache is the real owner of the process then I can't simply go
nuking the process as it would be a bit antisocial given that other non
Python stuff could be running in the same process. The other option of
destroying the Python interpreter in process and reinitialising it has
proven to have problems in the past and likely would cause more problems
than it solves.
--
Ticket URL: <https://code.djangoproject.com/ticket/24523#comment:17>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.59f0119f0d8a6f5d30f310cd042b9a6f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
