#36910: When using daphne, if some process is already listening on our preferred
port, `runserver` does not exit with a failure code.
-------------------------------+-----------------------------------------
Reporter: Eric Hanchrow | Type: Uncategorized
Status: new | Component: Uncategorized
Version: 6.0 | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+-----------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/36910>
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019c3f448ccc-ed0bef02-27d6-421e-bf90-22192caee97f-000000%40eu-central-1.amazonses.com.
