Django Runserver Crashes without Message - django

I've been working a project for months using Python3 & Django, never had issues regarding starting django but yesterday I formatted my Mac, I have the project in Github so today I clone the project and had bunch of issues with Psycopg2 and Pillow but eventually fixed it.
The problem now is that, when on the terminal I put python manage.py runserver, django simply crashes without any message and I don't know how to find the problem or view any logs regarding the crash, this is all I get:
(backend) ➜ src git:(master) ✗ python manage.py runserver
3Watching for file changes with StatReloader
Performing system checks...
After that it simply crashes and nothing else happens. Any ideas on how to debug this problem? I've tried cloning it again and building it but same results.

Related

Jupyter notebook hanging due to Django runserver

Some time ago I made a simple Django application. Recently, I started using Jupyter notebooks for Python and was wondering if I could run my application from such a notebook. To test that, I opened a new notebook and navigated to the top directory of the application:
%cd d:\adressen
To see if the application could be run from the notebook, I first tried:
!py manage.py makemigrations
It returned, as it should:
No changes detected
So far so good. Now starting the server:
!py manage.py runserver
In a sense nothing happend. No output, the cell label still showing as In[*]. Nevertheless, the server was running, for if I opened in my webbrowser the page http:\\localhost:8000, my application turned up and all features were working.
I fail to see why in the notebook makemigrations is handled correctly and runserver makes it hanging. The Jupyter console did not show anything that could have gone wrong.
Having looked at some other questions and answers about Jupyter and Django, I installed django-extensions and included it in the installed apps. That did not help. When I start Jupyter with python manage.py shell_plus --notebook, open a new notebook and use the same commands, the same happens.
Any suggestions on why this happens and how to overcome it are highly appreciated.
At last I think I found what is going on here and how to overcome it.
With the Jupyter shell command !py manage.py runserver Django indeed starts the server, but also wants to write to a console. There is no console, so Jupyter seems to hang.
When instead we use !start py manage.py runserver, not only Django starts the server, but also a console opens in which we see the standard Django output when opening a server.
In this way I can use a Jupyter notebook as an IDE for Django projects.

python can load GDAL, but django can't

I was able to successfully install gdal 1.11 and load it from python shell on my windows 32 bit machine. I can also verify its success by typing "gdalinfo --version" and getting the correct version info: GDAL 1.11.4, released 2016/01/25
However, when running "python manage.py shell" in django 1.11, I got error 127 'the specified procedure could not be found'. The error occurred when django called function lgdal = CDLL(lib_path)
I printed out lib_path, it is correct. The same function worked fine in my python shell.
Any idea why loading gdal111.dll would fail in the django environment when it has no problem in the python shell? Thanks.

Django Runserver crashes due to autoreload?

so i'm very new to Django. But my problem is as follows:
When I create a project, the runserver often won't start. I type:
python manage.py runserver
Powershell freezes for a while and says: "Python is not responding"
The Problem does not appear when typing:
python manage.py runserver --noreload
I am using Windows 10 and Django 1.10.6 as well as Python 3.6
The problem has also been reported on the forum of djangoproject but there was no solution offered. Is there any way to fix this?
Will disableling autoreload affect working with the Localhost?
Thank you.
I just started encountering this same bug tonight. I'm not sure how to fix it just yet or what causes it, but running with --noreload won't hurt anything. The server just won't reload when you make a Python change, so you'll have to restart the server yourself to test changes.

Can't start Django 1.7.1 development server

I migrated my Django app from 1.4.3 to 1.7.1
I got it working for a short while
but now every time I try to run the development server it gets stuck on:
C:\Users\DAVID\Documents\TinyTap-web\tinytap>python manage.py runserver
Performing system checks...
System check identified some issues:
WARNINGS:
?: (1_6.W001) Some project unittests may not execute as expected.
HINT: Django 1.6 introduced a new default test runner. It looks like this project was generated using Django 1.5 or earlier. You should ensure
. See https://docs.djangoproject.com/en/dev/releases/1.6/#new-test-runner for more information.
System check identified 1 issue (0 silenced).
the localhost is not working , also tried with other IP/ports = same results.
I could get rid of this warning by adding TEST_RUNNER = 'django.test.runner.DiscoverRunner' to the settings file, but still development server is not running
Apparently it was related to migrations and "CircularDependencyError".
After deleting the database , and the migration folders and running manage.py migrate
I was finally able to runserver
Trying creating a new project
django-admin.py startproject mysite
If it works then there's problem with the current project you're trying to run. (You'll need to give us more information for us to help)

can't get django to work in eclipse + windows

I've installed django on my windows machine, added the pydev and django plugins for eclipse, create a django project, and ran manage.py createapp to create one app. Now when I run manage.py runserver (via eclipse's "custom command" option") It says Validating models... but when I go to http://localhost:8000 I get no response, as though the server is not running. What am I doing wrong?
Try running with --noreload to avoid getting two processes. It helps with error output redirection in eclipse, and may give you more hints towards the actual problem.
Also, do the same from the command-line to see if you get the same problem.
Update: Per Fabio's comment above, you can work around this problem by hacking the code, as explained in this question.