I've run into an issue where shutting down django devserver in a container
(e.g. in kubernetes/openshift environment) doesn't work well. The original
report is at [2].
Explanation:
* kubernetes/openshift send SIGTERM to PID 1 in the container when
shutting the container down.
* If `manage.py runserver` is an entrypoint, it gets executed as PID 1 in
container.
* Linux kernel won't propagate SIGTERM to any process that is PID 1 (in or
outside of container) if it doesn't have a handler installed for this
signal.
The implication of this is that the container with django devserver will
not do "soft" shutdown on SIGTERM and Kubernetes/Openshift will wait for
timeout and kill the container with SIGKILL. Therefore the container will
keep hanging and occupying system resources during the whole timeout.
Even though I understand that people should only use devserver for
development and not for deployment, I think it's quite common to first
make the container working with devserver for development and then
consider Gunicorn or similar solution when moving from early stage of the
project. IOW, I think this would really be beneficial for people using
Kubernetes like environments to develop/deploy Django apps.
Thanks for considering!
[1] https://github.com/django/django/pull/9338
[2] https://github.com/sclorg/s2i-python-container/issues/93
--
Ticket URL: <https://code.djangoproject.com/ticket/28835>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_tests: 0 => 1
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/28835#comment:1>
Comment (by Slavek Kabrda):
I amended the PR with tests, so I believe it's now ready for review.
[https://github.com/django/django/pull/9338 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/28835#comment:2>
* needs_better_patch: 0 => 1
* needs_tests: 1 => 0
Comment:
Please uncheck `Patch needs improvement` when the Windows issue is solved.
--
Ticket URL: <https://code.djangoproject.com/ticket/28835#comment:3>
* needs_better_patch: 1 => 0
Comment:
I marked the test to be skipped on Windows, as I believe this is actually
not (easily) achievable on Windows. The Windows behavior is unaffected by
my patch. All tests pass now, I'm unchecking "Patch needs improvement".
--
Ticket URL: <https://code.djangoproject.com/ticket/28835#comment:4>
Comment (by Carlton Gibson):
Patch itself looks good.
There is some discussion on the PR as to whether this is quite the right
fix: in the ideal case this probably isn't Django's responsibility vs it's
a small change that should help some avoid a ??? moment, especially when
just experimenting.
Given this was initially Accepted (rather than DDN, or wontfix), I'm going
to mark this Ready for checkin, wherein it'll get a final review.
--
Ticket URL: <https://code.djangoproject.com/ticket/28835#comment:5>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/28835#comment:6>
* needs_better_patch: 0 => 1
* stage: Ready for checkin => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/28835#comment:7>
* status: new => closed
* resolution: => wontfix
Comment:
After discussion on the PR we're going to close this off in favour of
#21978 (having runserver use gunicorn).
In the meantime a specialised init process (or docker's `--init` flag) is
probably the way to go.
--
Ticket URL: <https://code.djangoproject.com/ticket/28835#comment:8>