Блог

Главная - Вопросы по программированию - Django — Debug устанавливается в True, когда это на самом деле не так

Django — Debug устанавливается в True, когда это на самом деле не так

#django #ubuntu #django-deployment

#django #ubuntu #django-развертывание

Вопрос:

Я развернул свой проект Django на Ubuntu и забыл установить для отладки значение False до самого конца, теперь я перенес последний коммит на сервер с установленным для отладки значением False. Итак, теперь, когда я пытаюсь получить доступ к несуществующему URL, например, он должен отображать мой пользовательский 404.html шаблон.

Вместо этого он отображает ошибку режима отладки 404, сообщающую мне, что Debug = True, даже если это не так, я проверил settings.py файл на сервере и отладка имеют значение False.

Я попытался перезапустить nginx и supervisor с помощью service nginx restart и supervisorctl restart my_app_name , но когда я ввожу несуществующий URL, он по-прежнему говорит, что для Debug установлено значение True.

Почему он все еще говорит, что для Debug установлено значение True?

ОБНОВЛЕНИЕ: после полученного ответа я просмотрел возможные предложенные проблемы и не нашел ни одной из них. Кроме того, когда я запускаю точно такой же проект на локальном компьютере, он отлично работает с Debug = False.

Если я запускаю на сервере тот ЖЕ САМЫЙ проект, с тем же точным кодом и файлами / файловой структурой (они «синхронизированы» с github), это показывает, что для отладки установлено значение True, поэтому должно быть что-то, связанное с конфигурацией на сервере.

ВТОРОЕ ОБНОВЛЕНИЕ: после добавления нового домена в ALLOWED_HOSTS список settings.py файл, он также игнорирует это. Так что это не просто проблема переменной DEBUG, она игнорирует каждое изменение, внесенное в settings.py файл. Может ли это быть кэширование Cloudfare? Если да, то как это предотвратить?

Комментарии:

1. Есть шанс, что это хероку?

2. Нет, это не так. Я использую сервер Ubuntu с собственным IP-адресом.

3. Тогда вам придется его отлаживать. Запустите /path/to/bin/python manage.py shell с помощью интерпретатора python, который использует супервизор, и введите import settings следующее по settings.DEBUG . Если это показывает True, значит, это True, и вы где-то переопределяете его. Если он показывает False, то, возможно, nginx не разговаривает с нужным приложением? Кэш Cloudflare? Действительно трудно догадаться…

4. Какой сервер WSGI вы используете? Мне часто приходится перезапускать gunicorn (мой WSGI по выбору) после изменений. Определяется ли значение DEBUG параметра переменной среды?

5. Я использую gunicorn с supervisor, и я несколько раз пытался перезапустить supervisor с supervisorctl restart app_name . Разве это неправильный способ перезапустить gunicorn?

Ответ №1:

Потому что это так. Общие причины:

  • DEBUG= False и 30 строк спустя DEBUG = True
  • DJANGO_SETTINGS_FILE указывает на другой файл, тогда вы изменили настройку отладки в
  • в нижней части файла настроек импортируется другой файл с общим именем local_settings.py , имеющий значение DEBUG=True
  • в нижней части файла настроек находится некоторая логика, которая импортирует переменные среды, перезаписывая предыдущие определения
  • DEBUG = 'False' # this is True

Комментарии:

1. Спасибо, что предложили свои решения, но я не столкнулся ни с одной из предложенных проблем. Кроме того, если я запускаю точно такой же проект с точно таким же кодом на локальном компьютере, он работает просто отлично, и для отладки установлено значение False, согласно settings.py

2. не могли бы вы запустить grep DEBUG . -R в папке django ?