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 36910 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` () - 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. " Uncategorized closed Uncategorized 6.0 Normal invalid Unreviewed 0 0 0 0 0 0