By default thin logs in a separate file (something like thin.0.log). This makes debugging hard since exceptions will be logged in thin.0.log while all the other information is in the Rails log. How can you force thin to log in the same file as Rails?
As annoying as it may be, that data is meant to be separated from the development.log or production.log (which is what I assume you're referring to). Thin logs handle everything related directly to the thin server as far as reasons why it can't start up, saying that it did, what port it's bound to, etc. The other logs are for your application itself, such as exceptions, page renders, requests, etc...
You'll be glad for this when you run into an issue with thin not starting due to a syntax error in a model or something. It's nicer to have one clean log for those instances, rather than filtering through thousands of lines of served static asset...
Rails is all about everything being organized and having its own place.
Related
My development Rails 5 server with Puma keeps freezing and hanging when sending multiple requests at one time from my separate frontend app to the Rails API. There is no error, it just hangs on the POST requests. When I try to kill the server with CTRL + C, nothing happens. I have to manually kill the port.
I've tried setting config.eager_load=true in development.rb. I've tried adding config.allow_concurrency in application.rb. I've Googled relentlessly to no avail. I am sending around 5 requests concurrently from frontend, so I believe this amount of requests is causing it, but I don't know for sure.
Has anyone else experienced this or have an idea of what needs to be done here? I can usually get all the requests coming back to the frontend successfully around 3-4 times, then the server just freezes.
It especially occurs after I change any one line of code in any file in the project while the server is running.
It's been nearly 2 years but I finally happened to stumble upon what had been causing my issue.
Basically it boiled down to a method in my code not being thread-safe. Since my current_user variable was only accessible from my controller, I had a before_action on my base controller to assign the current user to User.current so that I could access the current user globally via User.current, not just in my controllers.
So PLEASE make sure you're not dynamically updating classes like I this in your controllers. It is not thread-safe. I ended up following this thread-safe solution instead for my particular case: https://stackoverflow.com/a/2513456/7629239
What is your puma configuration? How many threads and workers(Puma workers not rails workers).
Ensure that your puma has enough threads, and that your db pool is large enough. Changing a line of code should not cause your server to get exhausted in resources. Are you using a watcher like watchman?
As part of the security procedures for our Rails application, we want to have an audit log of the commands that were run from rails console in our production environment.
This audit log should be persisted somewhere, such as a database, a file in an S3 bucket, or similar. If it could be written to the standard rails log, that might be OK too, as we already have a way to persist that.
We're currently hosted on Heroku. Heroku will log the event of firing up a console, but (a) Heroku provides no functionality for logging commands run from an active console, and (b) we'd like a more general-purpose solution.
Are there any pre-existing solutions for this out there?
If there is none, I'm trying to figure out how to monkey-patch IRB or Rails Console.
I've discovered that the data I need is already in
Readline::HISTORY
but I'm struggling to figure out where/how to hook into it.
Ideally, I'd like to capture each entry as (before?) it is sent to the interpreter, and quickly persist it somewhere (we already have Resque, so that may be a good solution). FWIW, sending the contents of Readline::HISTORY on Kernel.exit seems like it may be unreliable. For example, if a SIGKILL stops the process, then the history contents wouldn't be saved.
I have inherited the maintenance of a legacy web-application with an "interesting" way to manage concurrent access to the database.
The application is based on ruby-on-rails 2.3.8.
I'd like to set up a development environment and from there have two web browser make simultaneous requests, just to get the gist of what is going on.
Of course this is not going to work if I use Webrick, since it services just one http request at a time, so all the requests are effectively serialized by it.
I thought that mongrel could help me, but
mongrel_rails start -n 5
is actually spawning a single process and it seems to be single-threaded, too.
What is the easiest way of setting my development environment so that it responds to more than one request at a time? I'd like to avoid using apache and mod_passenger because, this being development, I'd like to be able to change the code and have it reloaded automatically on the next request.
In development mode, mod_passenger does reload classes and views. I use passenger exclusively for both development and deployment.
In production, you can (from the root of the rails app):
touch tmp/restart.txt
and passenger will reload the app.
Take a look at thin
http://code.macournoyer.com/thin/
I've got a rails app that is behind HAProxy and I'd like to ignore all of the Rails logging coming from the pings from the HAProxy servers. The servers are pinging ~1/sec and are really cluttering up the log file.
Haven't tested this, but it should work:
class Rails::Rack::Logger
def call_with_filter(env)
if env['REMOTE_ADDR'] == '10.0.0.1'
#app.call(env)
else
call_without_filter(env)
end
end
alias_method_chain :call, :filter
end
see railties-3.0.7/lib/rails/rack/logger.rb for the original.
The solution that I opted for was a little bit more systemic. I created a static textfile in the public directory and switched HAProxy to use this as its ping location. There is no logging and is less complex than a code solution.
I did try the example above and was able to get it working, but doing a monkey patch for this issue doesn't seem necessary, however if the requirements were a bit more complex (i.e. HAProxy had to hit the particular controller) then I'd opt for Roman's solution
The solution that I ended up going with was relatively low tech.
The goal of using HAProxy is not just to load balance, but to ensure that the nodes that are being directed traffic are actually up. This means that we wanted to have HAProxy not just hit the server to see if its up, but also test that Nginx and Passenger are up and functioning.
I put a static text file in the public assets of the rails project and have HAProxy hit the file. The file will be served up by the full stack and be a decent indicator that the services are up. As its a public asset, the hit does not appear in the log and the spamming is stopped.
Although this does not test much deeper into the Rails stack, the time to implement is lower than any coded solution, it doesn't add any additional complexity to the application and can be rolled into any future applications.
I have an edge case, although a very customer visible one, where Tomcat begins processing requests before all dependencies are properly loaded for a Ruby on Rails stack running underneath JRuby.
Once Tomcat is restarted, there is something similar to the following happening:
undefined method `utc_offset' for nil:NilClass
[RAILS_ROOT]/gems/gems/activesupport-2.3.8/lib/active_support/values/time_zone.rb:206:in `<=>'
This happens when the following code is invoked on one of my services:
#timezones = ActiveSupport::TimeZone.all
If you wait a few more seconds and refresh the requesting page, it'll load no problem.
Is there a way to ensure that Tomcat does not start processing these requests until the entire stack, ActiveSupport, ActiveRecord etc is loaded? Has anyone experienced any similar symptoms?
This sounds like a possible bug in JRuby-Rack, assuming that's what you're using to run your Rails app in Tomcat. JRuby-Rack is supposed to load the entirety of config/environment.rb before it will process requests, so I'm not sure how this would happen to you, but perhaps I've overlooked something. Could you share some more data (or maybe code or an app that reproduces the issue) about how you induced the error at http://kenai.com/jira/browse/JRUBY_RACK or http://bugs.jruby.org?
I'm not sure if there is something like that in Tomcat directly, but you can write a javax.servlet.Filter that will intercept all requests, and deny them until your application is loaded. When application is fully loaded, you ask filter to stop denying requests. (This isn't pure Ruby solution though).