CODEWITHSUNDEEP
pythondjangopython-2.7
user940281
user940281

Reputation: 41

Django manage.py runserver fails to respond

I'm running a vagrant box on Mac OS X. The VM is running Ubuntu 12.04, with Python 2.7 and Django 1.4.5. When I start up manage.py, I call it like this:

./manage.py runserver 0.0.0.0:8000

And if I visit http://127.0.0.1:8000 from within the VM, the text browsers I've tried report that the HTTP request has been sent and then wait for a response until the request times out. No response ever comes.

I can telnet to the port like this:

telnet 127.0.0.1 8000

And enter random gibberish, which manage.py reports as the following:

127.0.0.1 - - [05/Aug/2014 17:06:26] code 400, message Bad request syntax ('asdfasdfadsfasd') 127.0.0.1 - - [05/Aug/2014 17:06:26] "asdfasdfadsfasd" 400 -

So manage.py is listening on that port. But a standard HTTP request generates no response from manage.py, either in the console or in the browser.

I've tried using different ports which hasn't had any effect. Does anyone have any ideas?

UPDATE Some additional curl output.

Executing 'curl -v http://127.0.0.1:8000' returns '* About to connect() to 127.0.0.1 port 8000 (#0) * Trying 127.0.0.1... connected

GET / HTTP/1.1 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 127.0.0.1:8000 Accept: / '

Executing 'curl -v http://somefakedomain' results in '* getaddrinfo(3) failed for somefakedomain:80 * Couldn't resolve host 'somefakedomain' * Closing connection #0 curl: (6) Couldn't resolve host somefakedomain'

Upvotes: 2

Views: 2274

Answers (1)

user940281
user940281

Reputation: 41

Okay, so to reiterate my last post.

There was a call to a Django service that was failing on application startup. No error was thrown, instead it was absorbed by Sentry. Those who were already using the VM on their local machines had worked around the issue.

The issue was identified by importing ipdb and calling its set_trace() function. From the console, I stepped through the application, testing likely variables and return values until it refused to continue. This narrowed it down to the misbehaving service and its unthrown error.

The code has been updated with proper try/catch blocks and the error is now handled gracefully.

So to summarise: Not a malfunctioning VM, but a problem with code.

Upvotes: 2

Related Questions