Internal server error when DEBUG = False *and* page errors elsewhere in site?

[Vineyard Worker]

Not sure exactly how to express this question but here goes: What internal site/page- or query-related problems produce 500 errors in Wagtail? That is, what is expected to cause a site to throw a 500 error when the only problem is on a page that isn't currently being accessed? (Please assume all config settings are correct.)

Background: I just deployed a site on DigitalOcean using functioning, apparently error-free development code. After confirming the production site loaded ok and after checking a few pages--all of them looked fine--I set DEBUG to False. Result: 'Internal server error' / 500 page on any site access.

The reason I ask is that everyone gave me advice such as, "You must have a bad ALLOWED_HOSTS line in production.py" or "You probably left out a semicolon in your nginx config file" or "Check your logs." But if I'd had problems of that sort the site wouldn't have loaded at all. 

And with DEBUG set back to True, the site came back up. Nosing around a bit more thoroughly, I found a problem: there was one page, down the tree, that wouldn't load, evidently because it queried another page model to display content. I hadn't yet created any such pages in the production database (for that model that is the query's target.)

Turned DEBUG back to False and got the 500 error again. Then with DEBUG True, I created a page for the query target's model. The page containing the query now loaded error-free. Tried the site with DEBUG False, and now it comes up fine. 

 

I would have thought that a page querying another, non-existent page would have thrown an error only when the former were accessed. 

    

 

[Erwin Moojen]

I have experienced this too and it is related to Django, not Wagtail. Most probably some settings are off and are error messages suppressed when DEBUG = True. So I would recommend to check your logs and see what error is given, using DEBUG = True and correct them. In my personal experience, it was related to settings of a folder, but it can be very different with you. Would love to hear what it was in the end!

Op vrijdag 30 april 2021 om 00:42:58 UTC+2 schreef stumbledi...@gmail.com:

[Vineyard Worker]

Nice to have the experience validated. Although I fixed that one bad page it turns out that I'm still getting 500s when DEBUG = False. I now suspect that on DigitalOcean there's sometimes/often a significant lag (minutes? longer?) between changing settings and getting a response, so that when I thought I'd fixed the issue by fixing that one bad page, I hadn't really. After some minutes suddenly I was getting 500s again with DEBUG False. With DEBUG True though the site still loads and works. My server logs are clean but I'll try to get Django logging working—so far I'm getting nothing logged on the console (using the example logging code from Django central plugged into my settings file).  

[Vineyard Worker]

Once I had Django logs writing to a file instead of the console they produced copiously. They reported a number of problems with my site that aren't causing pages to fail when DEBUG = True. The key error among them seems to be / have been related to a missing entry for the favicon in the static manifest (the favicon was present where it belonged in the production static collection, ie post 'collectstatic') but evidently an entry for it had been dropped. By 'key error,'  I mean that I think it was after I fixed that particular error by re-runnning collectstatic that the site began to work with debugging disabled. However, the logs are still reporting a number of other problems that don't seem to interfere with site functioning/functionality.

For completeness sake and the possible benefit of anyone else whose site breakdown might be related to a missing favicon reference, re-running collectstatic didn't work at first. I had assumed that the original favicon file, the one that collectstatic is supposed to collect, was still in the expected location per settings.py, or in my, case production.py.  Wrong. As it turned out, all of the other original images were there, but not the favicon. collectstatic didn't help until I copied the favicon file from its collected location back over to the 'to be collected' location. After I did that, running collectstatic yet again did finally fix it. 

[Wifi Doctor]

can you provide a stacktrace?  try loading your site from the command line (inside the project folder).  You should get an

error message (stacketrace) explaining what your problem is.

--
You received this message because you are subscribed to the Google Groups "Wagtail support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wagtail+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/eb2c248d-f6a2-49c1-923d-7bbc1311bf38n%40googlegroups.com.

[Vineyard Worker]

Sorry, do you mean a command line alternative to python manage.py runserver ? Loading via ...runserver gives/gave no errors with debugging either enabled or disabled. See original post—with debugging enabled  the site ran fine,  without any errors on the console, and without any page faults. When debugging was enabled, the site still loaded without errors on the console, but I got an internal server error on every page access. 

My tentative conclusion is that in the default configuation DEBUG = True doesn't debug thoroughly enough. I could have been clearer in my original post, but I still have the same basic concern: DEBUG = True misses some errors that can crash a site, correct? If that's not the case, why did my site fail only after I switched debugging off?

(My primary reason for posting was not to get help fixing the specific error I was dealing with, as frustrating as that error was, but to understand better the limitations of DEBUG = True and how to get general advice for tracking down errors when DEBUG = True fails. I finally saw a reference somewhere else to Django's logging system, which I had somehow missed, and once I had set up Django logging I was able to find my particular problem and fix it. From now on, I'll want to keep the Django log running, unless someone knows of a good reason not to.) 

[Wifi Doctor]

sorry,

if using *nix, run "python3 ./manage.py shell"  

If your environment vars are not configured, make sure you're in the folder/path where 'manage.py' is.

you 'may' see a stacktrace.  if not, check your system log file or use:  tail -f /var/log/(whatever your log file name is...probably 'messages')

to capture in 'real time'

To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/9bbf4fe0-01bb-4cca-b8b3-c35275c1b916n%40googlegroups.com.