[Solved]-Django with gunicorn and nginx: HTTP 500 not appearing in log files


OK, it took long, but I found it all out:

  • The <h1>Server Error (500)</h1> response comes from Django’s
    django.views.defaults.server_error (if no 500.html template exists).
  • The <h1><p>Internal Server Error</p></h1> from the bonus question
    comes from gunicorn’s gunicorn.workers.base.handle_error.
  • nginx logs the 500 error in the access log file, not the error log file;
    presumably because it was not nginx itself that failed.
  • For /fail_now, gunicorn will also log the problem in the access log,
    not the error log; again presumably because gunicorn as such has
    not failed, only the application has.
  • My original problem did actually appear in the gunicorn error log,
    but I had never searched for it there, because I had
    introduced the log file only freshly (I had relied on Docker logs
    output before, which is pretty confusing) and assumed it would be
    better to use the very explicit InternalErrorView for initial
    debugging. (This was an idea that was wrong in an interesting way.)
  • However, my actual programming error involved sending a response
    with a Content-Disposition header (generated in Django code) like this:
    attachment; filename="dag-wönnegården.pdf".
    The special characters are apparently capable of making
    gunicorn stumble when it processes this response.

Writing the question helped me considerably with diagnosing this situation.
Now if this response helps somebody else,
the StackOverflow magic has worked once again.


may be server response 500 is logged in access_log not in errorlog

in nginx default file

access_log  /var/log/nginx/example.log;

i think <h1><p>Internal Server Error</p></h1> is generated by nginx in production `

in debug=False

raise exception is treated as error or http500,so unless you changed the view for handler500,default 500 error page will be displayed

debug =true
raise exception is displayed in fancy djnago’s debug page

Leave a comment