I need to fix some issues on an application written in Tornado. It is REST canvas app which use socket to communicate with the server. Sometimes it generates 500 error when user tries to logout during some nodes' loading. I tried to replace 500 response with 402 type by using Try block in certain handler, but I am still getting 500 in the client. So I need to get exact line of Python code that generates error. Unfortunately I am not sure how to check those as all my browser is showing is 500 error, that's it.
If you start your application from the command line and then trigger the HTTP 500 error, you should see a traceback written to the console. Or at least it will appear in the log file.
Or, update the code that creates the tornado.web.Application instance in your application's main file, and pass debug=True to the Application() constructor. That turns on several options including serve_traceback. Then you should see a full traceback in the error response, not just a "500".
Related
I have a django project which used the normal email admins on an unhandled exception when debug is set to False. ie in production.
I normally just review the error message and the stack trace. However I clicked on the request url link, which managed to recreate the error on the prouduction site (which then fired off another email).
What is this request url? Does it recreate the full http request (including the session etc..) which resulted in the original error?
Can I get the link to point to a local version of the site? (As after fixing a previous error clicking on the earlier request url has manged to create a recent error that we have been unable to reproduce, so it would be good to recreate this locally so it can be debugged.
Using Postman, when I make a PUT request to an endpoint which returns a 204 with content, Postman is unable to parse the response, and my collection runner stops that iteration, indicating that an error has occurred.
When run outside of the runner, Postman displays the following:
Other people have also had this problem
Unfortunately I cannot fix the non-standard endpoint. Is there a workaround that will let Postman continue without throwing an error, especially when using the collection runner?
The 204 (204 NO CONTENT) response from the server means that the server processed your request successfully and a response is not needed.
More here: https://httpstatuses.com/204
Actually as much as I know, if the server is sending a 204 with a payload response, the endpoint is not developed as it should.
This would be the main reason Postman is not showing a response payload. You will only be able to read response headers.
So if you send a PUT request, and only receive headers, it means everything is ok. If you spect data the server should be responding with a 200 code.
Now, said this, if postman is telling you that “it could not get any response” it means basically the server is not responding any thing. Now try to increase the timeout in the postman settings. It’s very probable that the server is taking to much time. Check outside the runner how much time it’s taking to response.
I hope this helps you.
I have a Django app running on a gunicorn server with an
nginx up front.
I need to diagnose a production failure with an HTTP 500 outcome,
but the error log files do not contain the information I would expect.
Thusly:
gunicorn has setting errorlog = "/somepath/gunicorn-errors.log"
nginx has setting error_log /somepath/nginx-errors.log;
My app has an InternalErrorView the dispatch of which does an
unconditional raise Exception("Just for testing.")
That view is mapped to URL /fail_now
I have not modified handler500
When I run my app with DEBUG=True and have my browser request
/fail_now, I see the usual Django error screen alright, including
the "Just for testing." message. Fine.
When I run my app with DEBUG=False, I get a response that consists
merely of <h1>Server Error (500)</h1>, as expected. Fine.
However, when I look into gunicorn-errors.log, there is no entry
for this HTTP 500 event at all. Why? How can I get it?
I would like to get a traceback.
Likewise in nginx-errors.log: No trace of a 500 or the /fail_now URL.
Why?
Bonus question:
When I compare this to my original production problem, I am getting
a different response there: a 9-line document with
<h1><p>Internal Server Error</p></h1> as the central message.
Why?
Bonus question 2:
When I copy my database contents to my staging server (which is identical
in configuration to the production server) and set
DEBUG=True in Django there, /fail_now works as expected, but my original
problem still shows up as <h1><p>Internal Server Error</p></h1>.
WTF?
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
I am using Jetty server with embedded web app. However, whenever I hit any resource which is not present it serves a default page which shows a message "Powered by Jetty".
This page is being served from org.eclipse.jetty.server.handler.DefaultHandler.handle.
I want write a custom handler for this, however while trying to register custom Handler in jetty.xml file, I am getting syntax exception and server doesn't start anymore.
I was able to resolve this issue by doing some tweaks along with changes mentioned in Deactivate Jetty's default 404 error handler.
I use the App Engine for run my application and want to test how it will handle server errors.
Is there any possibility to simulate an error 500 via the WebTest ?
I got around it using a try except loop.
try:
self.testapp.get('/')
self.assertEqual(1, 2, 'GET request should have resulted in a 405 error') # Purposely fail
except webtest.app.AppError:
pass
Another way is the following:
self.assertEqual("500 Internal Server Error", self.testapp.post('/', params={}, expect_errors=True).status, 'POST Request should have resulted in a 500 error')
Both methods still will cause traceback to appear but the test passes
A 500 error is just what your webapp returns to the client when it gets an uncaught exception. It's not a specific failure - just what it shows to your users when something unexpected goes wrong. Instead, you should unit-test your handlers to ensure they act as expected.