id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
19137	runserver child started via autoreload won't always exit cleanly	santtu	nobody	"When using django.utils.autoreload (for example, runserver with use_reloader option enabled) it is possible to get into a situation where you might think the server has been killed, but actually is not and is listening to the port.

Steps to reproduce:

1. Start application, when use_reloader is enabled (manage.py runserver)
2. Search for a pair of the manage.py processes (ps -aef --forest | grep runserver etc.), make a note of which is the parent and which is the child
3. Kill the parent using command-line kill ""kill -INT <parent pid>""
4. Look at ps output, and you'll find the child still alive, and via lsof -i | grep LISTEN you can see it is still listening on the server port.

Normally if you use runserver from a terminal, pressing control-C will send SIGINT to the whole foreground process group. Both the parent and child will thus receive SIGINT and will exit cleanly.

If you however kill the *parent* only, the child will not receive any signal, and thus will happily keep running.

This is a bit of a bummer when doing test automation, which tries to clean up the test environment by killing the parent -- but the child won't go away, and keeping server port reserved.

It is possible to do a semi-work-around by spawning runserver in its own process group, but it requires some careful environment crafting (and I haven't been able to get it reliably working on macos -- there are apparently some semantic differences in setpgrp wrt/ linux and macos). And of course is hardly obvious for anyone encountering this problem for the first time.

I have a patch for this and I'll make a pull request and link to that when I have a ticket id..
"	Bug	closed	Core (Management commands)	1.4	Normal	fixed			Accepted	1	0	1	1	0	0