django tutorial returns 'ERR_EMPTY_RESPONSE'

Question

I'm following the django tutorial: version 1.8, Ubuntu 10.04, python 3.4 in a virtual environment. I seem to create a django project (yatest) on my Ubuntu server just fine and I start the development server:

(v1)cj@drop1:~/www/yatest$ python manage.py runserver
Performing system checks...

System check identified no issues (0 silenced).
August 09, 2015 - 04:37:33
Django version 1.8.3, using settings 'yatest.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

but when I browse to http://myserver:8000 all I get in response is 'ERR_EMPTY_RESPONSE'.

This is the first part of the tutorial before an app is even created. At this early stage in the tutorial it doesn't mention any error log I can check. My telnet client doesn't say anything crashed, and 'ctl-c' will shutdown the server process with no complaints.

Using netstat -lntp I verified no other processes are using port 8000. I do not have Apache installed. I do have gunicorn and nginx installed but both are stopped and not in use yet in the tutorial.

I'm rather new to linux; I could use some help finding an error log or other debugging tools to solve this. I don't doubt I've missed some basic OS setting or something to enable TCP access, etc..

Thanks Clark

Withe

Can you link the tutorial you are following? – Anacreontic

Where are you accessing it from? The same machine, or a different one? And what happens if you use 127.0.0.1 as described in the tutorial? – Morgenthaler

@DanielRoseman Different machine. Other tutorials imply it should be accessible from outside even at this early stage, but if that's not the case, please let me know. – Withe

@Anacreontic Tutorial is here: michal.karzynski.pl/blog/2013/06/09/…. I'm at the part just after creating the django project. – Withe

Answer 1

Found my mistake. When starting a dev django server on dedicated server one MUST include the dedicated server's address in the command. This is not needed when launching a dev server on the same machine as your browser. So instead of

$python manage.py runserver

you have to run $python manage.py runserver <server ip>:8000.

So this is my inglorious start on stack exchange. You saw nothing! :P

Withe

I had the same issue running Django inside a container via docker! You saved my life – Bloodstain

it's been 7 hours of suffering, only to find that (THANKS A LOT) and find out that thing was actually very needed for containers. Why no tutorial says that... – Adalai

Answer 2

If you're running natively in an virtual envrionment, then you need to specify a port and address:

python manage.py runserver 127.0.0.1:8000

For containers, it's easiest to listen to all addresses:

python manage.py runserver 0.0.0.0:8000

For anybody using PyCharm in a docker environment, it's also worth knowing that PyCharm will override your docker-compose configuration to change the runserver command to bind to the port specified in the Host option in your Run/Debug Configurations window.

Make sure you set the Host to 0.0.0.0 and the port to 8000 if you want to use the debugger etc.

Oblige

Agree with the Pycharm comment. You can't have a custom port and host for running Django. It makes absolutely no sense at all. Why does the host have to be "0.0.0.0" and the port "8000"? – Wasp

I was using django in a docker container on my macbook and adding the 0.0.0.0:8000 did the trick. – Snooker

Answer 3

If you don't want the trouble to determine server ip (ie when you're using containers), you can listen to 0.0.0.0:8000

python manage.py runserver 0.0.0.0:8000

Arrow

Answer 4

I had the same issue, but for a different reason, so - on the off chance that someone else is in as weird as situation as mine...

I was consistently getting empty responses doing the django-girls tutorial.

I was doing it to get my basics of Python/Django because I'm working professionally on a project that uses them.

What I hadn't realised was that I had a container open (as in docker container) from my work, and that was somehow breaking the local mapping. I haven't worked out the details of why. The containers were not mapping to port 8000 - as far as I can see they only hit 5432 and 8443. (Here's the startup output of the containers.)

2024-07-02 10:44:58.627 UTC [1] LOG:  starting PostgreSQL 16.1 (Debian 16.1-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-07-02 10:44:58.689 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-07-02 10:44:58.689 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2024-07-02 10:44:58.697 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-07-02 10:44:58.709 UTC [29] LOG:  database system was shut down at 2024-07-02 10:43:39 UTC
2024-07-02 10:44:58.746 UTC [1] LOG:  database system is ready to accept connections
[2024-07-02 10:44:59 +0000] [1] [INFO] Starting gunicorn 22.0.0
[2024-07-02 10:44:59 +0000] [1] [INFO] Listening at: https://0.0.0.0:8443 (1)
[2024-07-02 10:44:59 +0000] [1] [INFO] Using worker: gthread
[2024-07-02 10:44:59 +0000] [7] [INFO] Booting worker with pid: 7
[2024-07-02 10:44:59 +0000] [8] [INFO] Booting worker with pid: 8

Anyway, in case anyone else trips over this. Stopping the containers fixed the empty response.

Potentiometer