When using daphne, if some process is already listening on our preferred port, `runserver` does not exit with a failure code.

[Eric Hanchrow]

I've created a simple standalone git project that reproduces the problem: ​https://github.com/offby1/repro-daphne-trouble.git

Here's a copy of the README, for convenience:

Briefly: if some server process is already listening on our preferred port, runserver does not exit with a failure code, but instead keeps running (even though the underlying daphne process has logged an error complaining about EADDRINUSE).

To reproduce the problem:

• clone this repository, and cd to the root (i.e., the directory that holds this very file)
• install uv (<​https://docs.astral.sh/uv/#installation>)
• run uv run python manage.py runserver; note that it's working fine
• in another window, again run uv run python manage.py runserver. This time, you'll see Listen failure: Couldn't listen on 127.0.0.1:8000: [Errno 48] Address already in use., but the process doesn't exit. The Listen failure message is expected, but the bug is that the process should exit with a nonzero status.

Notes:

• If, instead of uv run python manage.py runserver, you run uv run daphne repro.asgi:application (which is roughly equivalent), it works fine: the first process starts, and the second one both reports 2026-02-08 21:32:24,523 CRITICAL Listen failure: Couldn't listen on 127.0.0.1:8000: [Errno 48] Address already in use. *and* exits with status 1.

• If you check out the parent of this commit (i.e., the one before we added "daphne" to the project), and try running two copies of "runserver", they work fine (i.e., the second process exits with a status of 1). So the problem is in some interaction with "runserver" and "daphne".

• There was [a similar-seeming bug in daphne](​https://github.com/django/daphne/issues/552) that might have caused a similar problem, but it's irrelevant since it's been fixed for at least a year.