[Fixed]-Django DEBUG=False still runs in debug mode

by

4👍

✅

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.

👤Withnail

29👍

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! 🙂

👤Taraskin

9👍

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
👤Alberto Chiusole

6👍

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)
👤jturi

4👍

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

👤awwester

3👍

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

👤Shubham Harinkhede

2👍

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
👤Bruno Vermeulen

1👍

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.

👤femeloper

0👍

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.

👤xxg

0👍

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.

👤Laenka-Oss

Leave a comment