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'
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.
Related
Error picture
I've tried to execute my django-app with "ngrok". Added url to "ALLOWED_HOSTS" and other variables which need that. I did 'py manage.py runserver' and 'ngrok http 80' together => no result.
A few hours later, I figure out that you must run your ngrok from CMD, not from IDE Terminal.
P.S. If you set domain in 'C:\Windows\System32\Drivers\etc\ hosts' for your local address, that command help may help you:
ngrok http --host-header=rewrite mysite.com:80
where mysite.com - your domain name, :80 - your port.
Help me with this error please.
ERROR: for web Cannot start service web: driver failed programming
external connectivity on endpoint semestral_dj01
(335d0ad4599512f3228b4ed0bd1bfed96f54af57cff4a553d88635f80ac2e26c):
Bind for 0.0.0.0:8000 failed: port is already allocated ERROR:
Encountered errors while bringing up the project.
Go to Terminal and run command:
lsof -i:8000
Where 8000 is the port number.
The result will be like:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Python 123456 user ab type 123 000 TCP 0.0.0.0:8000
Now run command in terminal:
kill -9 <PID>
like
kill -9 123456
Then again run your server and the issue will be resolved.
The way i resolved this was by stopping the containers in execution and executing the one I wanted to start.
Use this command into your CMD for stop containers:
docker stop $(docker ps -a -q)
In the case you may want to delete them use this:
docker rm $(docker ps -a -q)
This happen to me time to time in my dev environment. Usually I have to restart docker service to get it working.
I encountered a very similar error. In my case, I had recently upgraded the native nginx version on the Linux box. After the upgrade, nginx automatically started (I had not noticed). When I deployed a docker image with nginx, the 2 nginx instances were competing for the same port (native and docker).
I saw it with:
> sudo netstat -nl -p tcp | grep 443
tcp 0a 0 0.0.0.0:443 0.0.0.0:* LISTEN #####/nginx: master
tcp6 0 0 :::443 :::* LISTEN #####/nginx: master
It was a bit confusing since I was trying to get nginx to run, and it said nginx was using the port. After I had typed docker-compose down, I realized nginx was still using the port, even though the nginx container was destroyed. That made me realize that the native nginx had started up again, even though I didn't manually start it.
My error message:
Cannot start service <webserver>: driver failed programming external connectivity on endpoint <server_instance>_webserver (...<guid>...): Error starting userland proxy: listen tcp 0.0.0.0:443: bind: address already in use
I've previously had the issue that I couldn't pinpoint the culprit in my Django app, causing all requests to 404. See the previous Stackoverflow question.
Since then I've tried to narrow down the issue and therefore started a new, VERY basic, Django app.
All the project consists of is:
$ django-admin startproject tempor
I've added the test directory and imported the test function
$ vi tempor/tempor/urls.py
from django.conf.urls import url
from django.contrib import admin
from tempor.views import test
urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'^test/$', test),
]
The views.py and the test function
$ vi tempor/tempor/views.py
from django.http import HttpResponse
def test(request):
return HttpResponse("OKAY")
Then I migrated the project - as suggested by Django:
$ python manage.py check
$ python manage.py migrate
Now I run the server:
$ python3 manage.py runserver 0.0.0.0:8282
Access from the server locally:
$ curl localhost:8282/test/
OKAY
$ curl <server-public-IP>:8282/test/
OKAY
Access from an external system (via proxy)
$ curl <server-public-IP>:8282/test/
<!DOCTYPE html>
<html lang="en">
[...]
<h1>Page not found <span>(404)</span></h1>
[...]
</html>
In the settings.py I have:
ALLOWED_HOSTS = ['*']
If I don't use '*', the external system is informed accordingly, as debugging is on:
$ curl <server-public-IP>:8282/test/
[...]
DisallowedHost at http://<server-public-IP>:8282/test/
[...]
This also occurs, if I try the same with a simple Python HTTP server - which the Django admin.py basically uses.
echo "OKAY" > /tmp/test/index.html
cd /tmp/test/
python -m http.server 8282
[...]
Local access:
$ curl localhost:8282/index.html
OKAY
$ curl <server-public-IP>:8282/index.html
OKAY
Remote access:
$ curl <server-public-IP>:8282/index.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
[...]
<p>Error code explanation: HTTPStatus.NOT_FOUND - Nothing matches the given URI.</p>
[...]
</html>
http.server log:
Serving HTTP on 0.0.0.0 port 8282 ...
<server-public-ip> - - [<timestamp>] "GET /index.html HTTP/1.1" 200 -
<proxy-ip> - - [<timestamp>] code 404, message File not found
<proxy-ip> - - [<timestamp>] "GET http://<server-public-ip>:8282/index.html HTTP/1.1" 404 -
For the moment, the proxy is a simple SSH port forwarding - which will later be replaces by an NGINX.
edit: The very same applies if I run uwsgi for the Django app:
$ uwsgi --http :8282 --module tempor.wsgi
Local accesses work - external requests 404.
Why do requests via a proxy 404 for me and how can I fix this issue?
Solved, but I don't understand why.
The issue was the direct access to the Python server using SSH port forwarding. An intermediate Nginx resolved the problem.
See my ServerFault question for further details.
For the server setup see the ServerFault question.
Client setup boils down to:
# SSH port forwarding, port 80 for Nginx access, port 8282 for direct Python webserver access
ssh -L 8181:<farawayhost-ip>:<80 or 8282> <sshuser>#<remotehost-ip>
# on a second terminal
export http_proxy=127.0.0.1:8181
curl <farawayhost-ip>
I setup a vagrant VM with django installed, and setup the port forwarding like this:
config.vm.network "forwarded_port", guest: 8000, host: 8001
So in the guest machine I run the django server like this:
python manage.py 0.0.0.0:8000
And the server starts up and tells me its running on http://127.0.0.1:8000
When I open up firefox on the host machine and point it to http://127.0.0.1:8001, it automatically redirects to https://127.0.0.1:8001 and I get this error:
An error occurred during a connection to 127.0.0.1:8001. SSL received
a record that exceeded the maximum permissible length. Error code:
SSL_ERROR_RX_RECORD_TOO_LONG
Nowhere in the settings.py file does it force https. I don't know whats causing it to redirect to https, or how I can go about figuring that out. Is this a problem with virtualbox, vagrant or django?
These error messages appear in the terminal where I run the server:
[06/Jan/2017 05:17:22] code 400, message Bad request syntax ('\x16\x03\x01\x00¥\x01\x00\x00¡\x03\x03d')
You're accessing the development server over HTTPS, but it only supports HTTP.
[06/Jan/2017 05:17:31] code 400, message Bad HTTP/0.9 request type ("\x16\x03\x01\x00¥\x01\x00\x00¡\x03\x03É\x8aVY#¦Û2\x
9c'\x1a5n¬òðÿ𪪮pÛ%å\x15#8jÕQé\x00\x00")
You're accessing the development server over HTTPS, but it only supports HTTP.
So the question is why is my browser trying to access the server over HTTPS?
You need to add this in your settings.py file :
SECURE_SSL_REDIRECT = False
For further reading, Read from here.
When I run the command:
fab -H localhost host_type
I receive the following error:
[localhost] Executing task 'host_type'
[localhost] run: uname -s
Fatal error: Low level socket error connecting to host localhost: Connection refused
Aborting.
Any thoughts as to why? Thanks.
Fabfile.py
from fabric.api import run
def host_type():
run('uname -s')
Configuration
Fabric 1.0a0 (installed from the most recent Github commit---b8e1b6a)
Paramiko 1.7.4
PyCrypto 2.0.1
Virtualenv ver 1.3.3
Python 2.6.2+ (release26-maint:74924, Sep 18 2009, 16:03:18)
Mac OS X 10.6.1
The important part isn't the "low level error" part of the message - the important part is the "Connection refused" part. You'll get a "connection refused" message when trying to connect to a closed port.
The most likely scenario is that you are not running an ssh server on your machine at the time that Fabric is running. If you do
ssh localhost
you'll probably get a message similar to
ssh: connect to host localhost: Connection refused
So you'll have to go out and set up an SSH server on your computer before you can proceed with Fabric from there.
I had the same problem, but the reason was different: While I could easily log in to the server via SSH (default port 22), fabric tried to connect on a closed port 9090.
Finally I recognized that I had defined "env.port=9090" in my old fabfile for some WSGI server setup; while that was never a problem, I updated my Python installation some weeks before, and fabric now uses env.port for its SSH connection.
I just renamed that config, and all is well again.
This can also happen in OS X 10.11.4 and Fabric 1.10.1, in the case where you are ssh'ing to a VM using Vagrant, which does port forwarding from localhost. In this case, localhost was resolving to the IPv6 ::1 address (not due to /etc/hosts file), and giving this error.
The fix was to force use of IPv4 by using the 127.0.0.1 address in the fabfile instead of the hostname. Using a hostname in /etc/hosts with this address didn't work.
You might also want to try these useful tips for debugging connection issues in Fabric.
env.roledefs = {
'role1': env.hosts[0:5],
'role2':[env.hosts[5],]
}
I encountered the same error if "role" value IS NOT A LIST. for example, the above code works but the following doesn't.
env.roledefs = {
'role1': env.hosts[0:5],
'role2':env.hosts[5],
}