Working my way through a Django tutorial, I have run django-admin startproject mysite. Now I cannot get the next step to work.
$ python manage.py runserver
>>>
$
where the blank line is where Ctrl-C was entered to break the loop. The >>> was the prompt I defined for the virtualenv. In other words, no output.
Most importantly, I get a connection refused error when connecting to http://127.0.0.1:8000. I do not get the the "'Welcome to Django' page, in pleasant, light-blue pastel" as described in the tutorial.
For other commands python manage.py works correctly. For example:
$ python manage.py check
System check identified no issues (0 silenced).
$ python manage.py shell --command 'import sys; print(sys.version)'
3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)]
$/ python manage.py shell --command 'import django; print(django.__version__)'
1.11.2
I am at loss for how explore further. I have tried:
Using multiple browsers
Varying the IP and port, including using LOCALHOST.
Turning off the proxy
Consulting other Stack Overflow, such as here and here
Rebooting my computer
Exploring Chrome's log's. Perhaps someone else can get something valueable out of these: Request Headers & Timing Diagram.
I am at loss for other steps to debug this problem.
If you didn't change something in the settings.py you should enter the service in
localhost:8000
Using the same machine where you are runing the server.
If you want to enter from another computer in the same network you should use
$ python manage.py runserver 0.0.0.0:8000
And change your "allowed hosts" to the ip of your computer or to *
Related
Trying to set up Django configurations for a public url.
So I ran this first.
$ echo "web: python manage.py runserver 0.0.0.0:\$PORT" > Procfile
$ git add Procfile
$ git commit -m "Specify the command to run your project"
In Procfile:
web: python manage.py runserver 0.0.0.0:\$PORT
release: python manage.py migrate
In Settings.py:
PORT = os.getenv("PORT", default="5000")
# SECURITY WARNING: don't run with debug turned on in production!
# DEBUG = True
DEBUG = os.environ.get('DJANGO_DEBUG', '') != 'False'
ALLOWED_HOSTS = ["url"]
In env.:
PORT=5000
SECRET_KEY=value
Was using the above commands and got
(portfolio) PS C:\Users\arund\Desktop\Code\Django\portfolio-project> heroku config:get PORT
5000
(portfolio) PS C:\Users\arund\Desktop\Code\Django\portfolio-project> heroku local
[OKAY] Loaded ENV .env File as KEY=VALUE Format
3:08:10 PM web.1 | CommandError: "0.0.0.0:\$PORT" is not a valid port number or address:port pair.
[DONE] Killing all processes with signal SIGINT
3:08:10 PM web.1 Exited with exit code null
I also used $PORT without the backslash and $. How would I proceed from here to make the public url working.
CommandError: "0.0.0.0:PORT" is not a valid port number or address:port pair does the same thing.
web: python manage.py runserver 0.0.0.0:5000 will work though for local
Use gunicorn to serve your web application via Heroku as described here:
https://devcenter.heroku.com/articles/python-gunicorn
Regarding your error, I think you're technically escaping the $ and so its not expanding the variable.
Try removing the \ or, for debugging purposes see if this works by hard coding the port you expect to be in $PORT and see if that works, if it does, I imagine you need to set the $PORT env variable.
Took me about 2 hours to finally figure out what was happening that's why I'm dropping this answer for anyone it might help. If you're using a Windows OS locally (say powershell on vscode), either $PORT or \$PORT will not be parsed as environmental variables. So you might want to test out with something hardcoded like 5000. But since the Heroku OS is Linux based, it is recognized. So in short, locally, you can use
'web: python manage.py runserver 0.0.0.0:5000'
and before pushing to Heroku, change the line to
'web: python manage.py runserver 0.0.0.0:$PORT'
(without the backslash, the backslash escapes on Linux).
I am learning Django so I've created many Django webapps under one directory. For example,
\webapps
\polls
\polls
\api
\manage.py
...
\ponynote
\ponynote
\frontend
\manage.py
...
I didn't use a virtualenv for developing django apps. I don't know whether it's the reason that causes the problem as below.
App 1
python manage.py runserver works all fine. (default port 8000)
App 2
python manage.py runserver still shows the App 1 page.
Method I tried:
change the port python manage.py runserver 8001, it shows App 2 page.
try to find the process ID PID, and kill it. No sign of port 8000.
However, this isn't the best solution since I can't change the port everytime when developing a new django app. Does anyone have a clue why this happens? Kudos.
Problem solved:
remove web browser cache. In my case, it's Chrome.
One effective solution would be to create a bash script for your use. Create 2 separate bash scripts for your projects (The same dir where your project's manage.py can be found).
For App 1:
# script- App 1
python manage.py runserver 0.0.0.0:8000
For App 2:
# script- App 2
python manage.py runserver 0.0.0.0:8080
And for running:
./yourbashscriptfile
I have a Django site running in Docker containers, which uses docker-compose to manage the various containers (database, nginx, etc.). There are a few Django tasks that I use for site maintenance using the Django manage.py command. They commands take the form of:
manage.py updateflickr --settings=mysite.myproj.prod
Running under docker-compose, they look like:
docker-compose run --rm app manage.py updateflickr --settings=mysite.myproj.prod
My problem is that when I try to run these same commands using Fabric, it appears that the settings file I am specifying is not being used. Django is returning database connection errors, which typically mean that it is not getting the correct database information, or in this case the connection specified in mysite.myprod.prod
My Fabric file looks like:
import os
from fabric.api import *
env.hosts = ['myserver.com']
env.user = "myuser"
env.key_filename = '~/.ssh/do_rsa'
env.shell = '/bin/bash -c'
#task
def updateflickr():
run('docker-compose run --rm app python manage.py updateflickr --settings=mysite.myproj.prod')
I have also expirimented with setting the DJANGO_SETTINGS_MODULE environment variable in my docker-compose.yml but am getting the same results. Finally, the last thing I tried was wrapping the command in a shell script. Same results - if I run on the server, it runs fine. If I run the shell script from Fabric, I get database connection issues.
UPDATE
I am not so sure this is so much a question about Fabric, then a question about how docker-compose runs. If I try the following:
ssh -t me#myserver.com 'docker-compose run --rm app python manage.py updateflickr --settings=mysite.myproj.prod'
I still get the same results. There must be something different about loading up an interactive shell with just sending a command. I have tried using ssh with and without a -t flag, because docker-compose might need a pty active.
I installed Django, and it works. I set it up so it uses my mysql database, and I started a project. So far so good.
I followed the tutorial on setting up your first Django app over at
https://docs.djangoproject.com/en/dev/intro/tutorial01/
It is a tutorial over setting up a pre-existing poll app where everything has practically been built for you. The database structure has even been handled.
I ran:
python manage.py startapp polls
python manage.py sql polls
python manage.py syncdb
I didn't receive any kind of success message so I went into my phpmyadmin, and hooray! There are new tables and rows in my database.
Their tutorial then told me to run:
python manage.py shell
and that I'd see some database stuff, but I didn't. Why could this be? I ignored it and went on to step two. I still hadn't set DEBUG in my settings.py to False so I did. Only to get a 500 error.
After some digging I read I needed to add:
ALLOWED_HOSTS = ['my ip address'];
I did this and now after running:
python manage.py runserver myip:8000
When I try to access Django in my browser I get a
Not Found
The requested URL / was not found on this server.
Obviously / changes to a different location when navigating to those places as well, but the point is I get a 404 no matter what.
So I look at my terminal and I have a yellow message in my terminal that says.
"GET / HTTP/1.1" 404 74
and there is 1 message like this for each place I tried to access.
I'm thinking there is a Python package that I don't have installed on my server?
I do not want to use ALLOWED_HOSTS ['*'] I read that this is bad practice. I did try it and it produces the same results as using my ip address in place of the * (I just wanted to add that extra piece of info in case it helps)
If you want to use the database shell, you should run the dbshell command instead of shell as in your post, like this:
python manage.py dbshell
If you run shell, you get a Python shell, where you can easily import and inspect the Python objects of your project.
On your local PC, it's better to have DEBUG = True in your settings.py. That way you don't need to bother about ALLOWED_HOSTS, because in debug mode all hosts are allowed. Secondly, when you get a 404 error in debug mode, the page will show you the valid URLs that you can try.
The Django tutorial certainly works. The only way it won't work for you is if you missed a step or mistyped something somewhere. If you start over and pay extra attention, I think it will work.
I've been trying to trudge through the docs and examples to get my Django running through upstart so I can have it running all the time but am unable to so.
Here's my upstart configuration file located at /etc/init/myapp.conf:
start on startup
#expect daemon
#respawn
console output
script
chdir /app/env/bin
exec source activate
exec /app/env/bin/python /app/src/manage.py runserver 0.0.0.0:8000 > /dev/null 2>&1 &
end script
When I type sudo service myapp start, the console says that it has started but it doesn't seem to be running.
Is it possible to see some debugging output to see what's going wrong?
I need to run my Django application as another user — i.e. djangouser. How can I do so?
(I've been commenting out some lines to test where the service is going wrong). This is not for production use but my internal development use only.
Thanks.
Edit #1:
I have wrapped both my commands into a simple script at /app/run.sh
#!/bin/bash
cd /app/env/bin
source activate
cd /app/src
python manage.py runserver 0.0.0.0:8000 > /dev/null 2>&1 &
..and I've modified my /etc/init/myapp.conf to
start on startup
expect daemon
exec su - djangouser -c "bash /app/run.sh"
When executing sudo service myapp start — the application starts but the PID is wrong and I can't seem to kill it with sudo service myapp stop
Any ideas?
Change:
exec source activate
By just:
source activate
This will load the virtual environment. You should probably drop the other "exec". If that doesn't work, please post your upstart logs.
A couple of remarks:
logging the output to somewhere else than /dev/null might be useful :)
runserver is not ment to be stable, I see it crashing sometimes and in that case i guess you'll need to force upstart to reload, or put the runserver call in a while loop
you will not be able to use an interactive debugger like ipdb with this setup
How about using nginx and uwsgi with your virtualenv. this will give you a production like environment but will also start your django app at start up. if you are using ubuntu 10 you should take a look at uwsgi-python, otherwise just install the latest uwsgi. i usually start my virtualenv in uwsgi like so : sudo nano /etc/uwsgi-python/apps-available/app.xml
<uwsgi>
<socket>127.0.0.1:8889</socket>
<pythonpath>/home/user/code/</pythonpath>
<virtualenv>/home/user/code</virtualenv>
<pythonpath>/home/user/code/app</pythonpath>
<app mountpoint="/">
<script>uwsgiApp</script>
</app>
</uwsgi>
also setup yournginx files at /etc/nginx/apps-available/default (the file is a bit straight forward). this will help you have your django app at all times,
su is problematic becouse it forks the process. You can use sudo -u djangouser instead or simply add
setuid djangouser
in your conf file.
This should work on Ubuntu 14.04 and possibly other versions as well:
root#vagrant-ubuntu-trusty-64:/etc/init# service my_app start
my_app start/running, process 7799
root#vagrant-ubuntu-trusty-64:/etc/init# cat /var/log/upstart/my_app.log
Performing system checks...
System check identified no issues (0 silenced).
You have unapplied migrations; your app may not work properly until they are applied.
Run 'python manage.py migrate' to apply them.
June 30, 2015 - 06:54:18
Django version 1.8.2, using settings 'my_test.settings'
Starting development server at http://0.0.0.0:8080/
Quit the server with CONTROL-C.
root#vagrant-ubuntu-trusty-64:/etc/init# service my_app status
my_app start/running, process 7799
root#vagrant-ubuntu-trusty-64:/etc/init# service my_app stop
my_app stop/waiting
root#vagrant-ubuntu-trusty-64:/etc/init# service my_app status
my_app stop/waiting
Here is the config to make it work:
root#vagrant-ubuntu-trusty-64:/etc/init# cat my_app.conf
description "my_app upstart script"
start on runlevel [23]
respawn
script
su vagrant -c "source /home/vagrant/dj_app/bin/activate; /home/vagrant/dj_app/bin/python /home/vagrant/my_test/manage.py runserver 0.0.0.0:8080"
end script