In my rails app, when ever the mysql service is stopped. I see a
/!\ FAILSAFE /!\ Tue Dec 28 14:37:59
+0530 2010 Status: 500 Internal Server Error Mysql::Error
I could not catch this exception in my rescue_action_in_public exception handler to give a custom error msg. Is there anyway to catch this exception?
This link appears to explain what you ask. I can't speak to it's applicability in your particular situation, however.
http://www.simonecarletti.com/blog/2009/11/re-raise-a-ruby-exception-in-a-rails-rescue_from-statement/
Related
In my ApiController I have:
rescue_from Exception, with: :render_exception_error
def render_exception_error(exception)
raise exception if Rails.env.test?
logger.error(exception)
render json: { error: 'An error occurred' }, status: 500 unless performed?
end
I want that method to also report the error to Sentry.
Do you know if by doing the line that does logger.error(...) it automatically logs it in Sentry too?
Or do I have to manually do Raven.capture_exception(exception) or something like that? Will this be done in the background?
Edit 2022
Raven is deprecated since a few months now and you should use the new Sentry gem.
To answer the question, which is Report errors manually from Rails to Sentry, you can check the documentation here: https://docs.sentry.io/platforms/ruby/guides/rails/usage/
TL;DR you can capture exception with
Sentry.capture_exception(exception)
Or you can capture a message with
Sentry.capture_message('Something went wrong')
In my Rails app I'm rescuing from all possible error, therefore it's possible that some 500 are not correctly sent to Rollbar and I want to fix it. I'm reviewing the documentation but without a meaningful answer.
Edit:
To be more clear, I have couple methods where I can handle all errors but in one place I've got something like this:
rescue_from :all do |error|
title = Rails.env.production? ? 'Error 500' : error.message
Rollbar.notify
render_jsonapi_errors(
title: title,
status: 500,
error: error
)
end
And I think I have to add some logic because in this case I don't send this message to rollbar because of this rescue_from :all (I cannot just delete this). Is there something like Rollbar.notify ?
Edit2:
After adding Rollbar.notify I don't see that app is trying to connect to the Rollbar
Output from rails s
Started GET "/" for 127.0.0.1 at 2019-05-17 17:09:56 +0200
NameError - uninitialized constant ApplicationController::ActionVew:
app/controllers/application_controller.rb:4:in
<class:ApplicationController>'
app/controllers/application_controller.rb:3:in'
app/controllers/root_controller.rb:3:in `'
Started POST "/__better_errors/5b518f578013d9ea/variables" for
127.0.0.1 at 2019-05-17 17:09:56 +0200
The better_errors gem (shown in your output) swallows errors in development mode.
It's a common-enough problem that we have a section of our Honeybadger documentation specifically for it: https://docs.honeybadger.io/lib/ruby/support/troubleshooting.html#the-better_errors-gem-is-installed
I have an application running on NGINX/Passenger in production environment. Most of the pages render fine, but some do not. The server returns the static 404 error page, but when checking the production log, the following is appended:
Started GET "/upload" for 92.111.174.132 at 2015-11-26 14:07:50 +0000
Processing by Upload::StaticController#index as HTML
Rendered upload/static/index.html.erb within layouts/upload (1.1ms)
Completed 500 Internal Server Error in 8.0ms
Note that there are no error messages or backtraces; this is really all there is. I've checked NGINX's error log and it does not report an error. I really don't know where to go from here.
I have small application on Rails 2.3.2, served with nginx+thin(127).
OS FreeBSD 7.1, DB - Posgresql.
Twise at this week my app has fall.
In log I get something like (~2-50 request per second):
/!\ FAILSAFE /!\ Mon Oct 04 20:13:55 +0300 2010
Status: 500 Internal Server Error
bad content body
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/vendor/rack-1.0/rack/utils.rb:311:in `parse_multipart'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/vendor/rack-1.0/rack/request.rb:125:in `POST'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/request.rb:428:in `request_parameters'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/request.rb:381:in `parameters'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/base.rb:1279:in `assign_shortcuts'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/base.rb:518:in `process_without_filters'
Or:
/!\ FAILSAFE /!\ Tue Nov 09 09:24:39 +0200 2010
Status: 500 Internal Server Error
IP spoofing attack?!
HTTP_CLIENT_IP="XX.XX.XX.XX"
HTTP_X_FORWARDED_FOR="192.168.XX.XX, YY.YY.YY.YY"
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/request.rb:229:in `remote_ip'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/base.rb:1372:in `request_origin'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/base.rb:1304:in `log_processing_for_request_id'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/base.rb:1296:in `log_processing'
/usr/home/../../history/vendor/rails/actionpack/lib/action_controller/base.rb:522:in `process_without_filters'
After that system rests into max open file limit (I guess it open by postgesql sessions), postgresql can't establish new connection and app fall.
Any suggestion, how I can protect my asspp in this situation?
Quoted from rails 2.3 release notes :
The fact that Rails checks for IP spoofing can be a nuisance for sites that do heavy traffic with cell phones, because their proxies don’t generally set things up right. If that’s you, you can now set ActionController::Base.ip_spoofing_check = false to disable the check entirely.
I have a rails app that is working fine except for one thing.
When I request something that doesn't exist (i.e. /not_a_controller_or_file.txt) and rails throws a "No Route matches..." exception, the response is this (blank line intentional):
HTTP/1.1 200 OK
Date: Thu, 02 Oct 2008 10:28:02 GMT
Content-Type: text/html
Content-Length: 122
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Status: 500 Internal Server Error
Content-Type: text/html
<html><body><h1>500 Internal Server Error</h1></body></html>
I have the ExceptionLogger plugin in /vendor, though that doesn't seem to be the problem. I haven't added any error handling beyond the custom 500.html in public (though the response doesn't contain that HTML) and I have no idea where this bit of html is coming from.
So Something, somewhere is adding that HTTP/1.1 200 status code too early, or the Status: 500 too late. I suspect it's Apache because I get the appropriate HTTP/1.1 500 header (at the top) when I use Webrick.
My production stack is as follows:
Apache 2
Mongrel (5 instances)
RubyOnRails 2.1.1 (happens in both 1.2 and 2.1.1)
I forgot to mention, the error is caused by a "no route matches..." exception
This is a fairly old thread, but for what it's worth I found a great resource that includes a detailed description of the problem and the solution. Apparently this bug affects Rails < 2.3 when used with Mongrel.
The article that helped me understand the problem & write my own patch.
An official Rails bug ticket that includes a patch for Rails 2.2.2.
This html file is coming from Rails. It is encountering some sort of error (probably an exception of some kind, or some other unrecoverable error).
If the extra blank line between the Status: header and the actual headers is there, and not just a typo, then this would go a long way to explaining why Apache is reporting a 200 OK message.
The Status header is how Rails, PHP, or whatever tells Apache "There was an error, please return this code instead of 200 OK." The fact there is a blank line means something extra is going on and Ruby is outputting a blank line before the error output for whatever reason. Maybe it's previous output from your script. The long and short of it is though, the extra blank line means that Apache thinks "Oh, blank line, no extra headers, this is all content now.", which would be consistent with the Content-Length header you provided.
My guess for why there's a blank line would be previous script output, perhaps a line ending at the end of a fully script page. As to why the 500 error is happening, there isn't nearly enough info here to tell you that. Maybe a file I/O error.
Edit: Given the extra information provided by Dave about the internals, I'd say this is actually an issue with the proxying that goes on behind the scenes... I couldn't tell you exactly what though, beyond what's already been said.
This is coming from rails itself.
http://github.com/rails/rails/tree/master/actionpack/lib/action_controller/dispatcher.rb#L60
The dispatcher is return an error page with the status code of 200 (Success).