为什么只有当 Debug=False AND db 设置为 Heroku 上的生产数据库时，django 才会在服务器 500 上失败？

Question

When we run $ python manage.py runserver --settings=project.settings.local there are 4 different possible combinations:

1. Debug=True && DB=local => Runs fine
2. Debug=True && DB=production => Runs fine
3. Debug=False && DB=local => Runs fine
4. Debug=False && DB=Production => Server 500 error

The fourth one is simultaneously: the most important, the hardest to debug, and the only one that fails.

Our django settings are setup with this structure:

settings
├── base.py
├── __init__.py
├── local.py
└── production.py

For this test we only used local.py and modified the contents for each run.

For Debug=True and DB=local this is the local.py file:

from project.settings.base import *

DEBUG = True
TEMPLATE_DEBUG = True

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': ***,
        'USER': ***,
        'PASSWORD': ***,
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

For Debug=False and DB=production this is the local.py file used:

from project.settings.base import *

ALLOWED_HOSTS = ['*']

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': ***,
        'USER': ***,
        'PASSWORD': ***,
        'HOST': '***.amazonaws.com',
        'PORT': '5432',
    }
}

We also ran it with Debug=True and DB=production as well as Debug=False and DB=local, both of which worked.

The DB settings were copied directly from the Heroku configuration and the connection to the database works great as long as Debug is set to True, so we're pretty sure it's not a DB schema or connection problem. We just can't figure out how it's possible that the production DB works when Debug is True, and it runs with DB set to False with the local DB, but for some reason when the two are combined it fails. We've also deployed the code to Heroku and confirmed that it runs with Debug set to True but fails with the same Server 500 error when Debug is set to False.

For reference, this is the contents of our base.py :

import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))

# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/1.6/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = ***


# Application definition

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'appname', 
)

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

ROOT_URLCONF = 'project.urls'

WSGI_APPLICATION = 'project.wsgi.application'

# Database
# https://docs.djangoproject.com/en/1.6/ref/settings/#databases

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

# Internationalization
# https://docs.djangoproject.com/en/1.6/topics/i18n/

LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.6/howto/static-files/

STATIC_ROOT = 'staticfiles'
STATIC_URL = '/static/'
STATICFILES_DIRS = ( os.path.join(BASE_DIR, 'static'), )

Our googling has come up with a lot of people misconfiguring the ALLOWED_HOSTS variable and ending up with similar symptoms but that doesn't seem to be our problem. Does anybody have any insight as to what could be causing this problem?

As requested, here is production.py, although it should be noted that this settings file was never used in this experiment.

from project.settings.base import *

import dj_database_url

DEBUG = False
TEMPLATE_DEBUG = False

ALLOWED_HOSTS = ['*', '.***.com', '.herokuapp.com', 'localhost', '127.0.0.1']

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': ***,
        'USER': ***,
        'PASSWORD': ***,
        'HOST': '***.amazonaws.com',
        'PORT': '5432',
    }
}

STATICFILES_STORAGE = 'whitenoise.django.GzipManifestStaticFilesStorage'

Answer 1

I have had the same issue. But then I removed this row in settings.py

STATICFILES_STORAGE = 'whitenoise.django.GzipManifestStaticFilesStorage'

Now I dont have 500 error when DEBUG=False. But probably, I guess gzip functionality doesnt work anymore.

Answer 2

What you should be doing here is this:

• Open up your Heroku logs by running $ heroku logs --tail in one terminal window.
• In another terminal window run $ heroku ps:restart to restart your dynos.

Watch the logs, and see the actual traceback. This will tell you exactly what's going on. Based on your configuration it could be a number of issues.

Answer 3

The solution for me was to run python manage.py collectstatic .

If you run $ heroku logs --tail inside terminal before doing this, the log will tell you what static files cannot be found (404).

Answer 4

Configuring the server e-mail and seeing the stack trace as mentioned by Two-Bit Alchemist was the key. We added these lines to our settings:

EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = '***'
EMAIL_HOST_PASSWORD = '***'
EMAIL_PORT = 587
EMAIL_USE_TLS = True
SERVER_EMAIL = EMAIL_HOST_USER

And received an e-mail with this error in the stack trace:

ValueError: The file 'stylesheets/application.css' could not be found with <whitenoise.django.GzipManifestStaticFilesStorage object at 0x7fdcebb94550>.

We'd had problems with static files before but though we'd fixed them. The css file it's complaining about not being able to find doesn't exist anymore and isn't referenced anywhere so I'm not sure why this error is even coming up, but we fixed it by adding an empty application.css file.

Answer 5

I hope this helps someone someday. I had this similar problems and it took a while before i fixed it. Check your <a></a> tags. If an href attributes points to a template/link that don't exist. You might encounter such .

Answer 6

something here helped me:

I had a static css file link (and honestly, it had just a few lines), once I removed the link, and inserted into a tag in my main.html, it worked just fine: with DEBUG=False

:D