CODEWITHSUNDEEP
django
awwester
awwester

Reputation: 10162

django DEBUG=False still runs in debug mode

I'm having issues setting my DEBUG = False on my deployed server (on heroku).

I don't believe I've seen this before, but setting debug to false is not getting rid of debug mode for my project. This means that when there are 500 errors it shows the error, and 404 errors are showing all my urls.

What's strange is that when i log into the server and run get the setting value from django.conf import settings settings.DEBUG it shows as False, which is what I set it to for the production server. TEMPLATE_DEBUG is also set to False.

I don't know I've ever seen this before where DEBUG = False but it's still acting in debug mode. Any ideas?

EDIT:

Thought I'd put this little note too because it's very common for people to be getting 500 or 400 errors when switching debug to False. I am not getting any errors, my project is just acting like it's in DEBUG mode.

# settings/dev.py
from .base import *

DEBUG = True
TEMPLATE_DEBUG = DEBUG

if not DEBUG:
    ALLOWED_HOSTS = ['localhost']

SECRET_KEY = 'localsecret1234123412341234'


# settings/prod.py
from .base import *

import dj_database_url, os

DEBUG = os.environ.get("DEBUG", False)
TEMPLATE_DEBUG = DEBUG

ALLOWED_HOSTS = ['mydomain.com']
SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]

STATICFILES_STORAGE = 'whitenoise.django.GzipManifestStaticFilesStorage'
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

DATABASES = {}
DATABASES['default'] =  dj_database_url.config()

Upvotes: 18

Views: 24542

Answers (11)

Erick Oziel
Erick Oziel

Reputation: 1222

Restart your terminal . Several answers here are helpful, but I found that restarting my terminal was also necessary to resolve the issue. I hope this helps!

Upvotes: 0

Laenka-Oss
Laenka-Oss

Reputation: 994

I had the same issue & none of the solutions worked. My error stems from the the server configuration. I have multiple apps served by NGINX & GUNICORN. One of the apps is linked with the default server.

This means that any request not matching any of the IP:port listening pair server blocks is served by the default server. While debugging I happened to have set the settings.py of the app linked with the default server block to DEBUG=True & forgot to set it back to DEBUG=False.

So bringing settings.py of the default app's server block back to DEBUG=False, solved the issue.

Upvotes: 0

xxg
xxg

Reputation: 86

I got the same error that OTREE_PRODUCTION=1 gives error 500 on Heroku. What I did is to make a new app (Note to change Heroku stack to make it compatible with your Python version) , upload codes to this new app, and set OTREE_PRODUCTION=1 for this new app.

Upvotes: 0

Bruno Vermeulen
Bruno Vermeulen

Reputation: 3455

When you use the module decouple (pip install python-decouple) make sure you cast DEBUG to a bool. Thus settings.py should have the following line:

from decouple import config

DEBUG = config('DEBUG', default=False, cast=bool)

where in the .env file

DEBUG = False # or True

Upvotes: 2

Shubham Harinkhede
Shubham Harinkhede

Reputation: 111

DEBUG takes Boolean value.

The os.environ.get("DEBUG", False) returns string value.

All the string value while typecasting return True. That's why the DEBUG is True.

 print(bool(os.environ.get("DEBUG", False))) # output: True
 print(bool("False"))  # output: True
 print(bool(""))  # output: False

To solve issue in heroku don't set any value to config var. it will return null string and after typecasting it will return False: enter image description here

Upvotes: 3

femeloper
femeloper

Reputation: 96

I also experienced this problem as I was loading the debug setting from an environment variable DEBUG = os.environ.get('DEBUG_MODE')).

This set the DEBUG value as a string, not a boolean.

To fix this, I hardcoded DEBUG = False in my prod settings file.

Upvotes: 1

Taraskin
Taraskin

Reputation: 792

The root cause of issue - False translated to 'False' string not bool.

Used next solution (settings.py):

DEBUG = os.getenv('DEBUG', False) == 'True'

i.e.: in this case DEBUG will set to (bool) True, only if the environment variable is explicitly set to True or 'True'.

Good luck configuring! :)

Upvotes: 31

jturi
jturi

Reputation: 1743

If somebody is using python-decouple for env variables and having trouble with DEBUG you have to use this line to retrieve booleans:

from decouple import config
DEBUG = config('DEBUG', default=False, cast=bool)

Upvotes: 6

Alberto Chiusole
Alberto Chiusole

Reputation: 2784

As a note for others: I had the same problem; I configured my production website on a VM with gunicorn and nginx, following the tutorial for ubuntu 16.04 from the digital ocean documentation.

I wasn't able to turn off the debug mode, even when restarting the nginx systemd's service: the solution was to restart also the gunicorn service:

# systemctl restart nginx gunicorn

Upvotes: 9

Withnail
Withnail

Reputation: 3178

I'll put this as an actual answer for people that come after.

There are three main areas that this can happen, where 'this' is basically:

I've changed something in my settings, but it doesn't seem to be reflected in the operation of my app!

  1. Server hasn't been reset after code changes made.
  2. Local and Dev settings haven't overridden/or are overriding in unexpected ways
  3. A local Environment Variable is overriding the attempt at hardcoding it

On Heroku, as in this example, Environment Variables are set this way. A more general guide to using them in Linux enviroments is available here.

Using an example from the question, you can see the environment variables being used in: 

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]

This uses the os library to go out to the system, and check for an environment variable called DJANGO_SECRET_KEY.

A better example is the:

DEBUG = os.environ.get("DEBUG", False)

This is good because it tries to get it from the environment, and if that fails, uses the second value in the tuple as the default: in this case, False.

During the course of debugging, you can hunt down your settings using printenv from the linux shell, which will print out all of the available EnvVars. If they're not there, you can set them in the format:

export DJANGO_SETTINGS_MODULE=mysite.settings

In this instance, it's probably better to unset the environment variable, rather than typecasting, as per this related answer.

Upvotes: 4

awwester
awwester

Reputation: 10162

This ended up being an issue with the config variable being "False" instead of False, and so debug wasn't properly set to the boolean value. Shoutout to @WithNail for helping get to the answer

Upvotes: 4

Related Questions