I have 2 Ruby on Rails projects. When I start a rails server for the first project and login, I see this in the console:
Started POST "/users/sign_in" for 127.0.0.1 at 2013-11-15 10:40:24 +0100
When I start the rails server for the second project and login, I see this in the console:
Started POST "/users/sign_in" for 127.0.0.1 at 2013-11-15 10:39:46 +0100
Processing by SessionsController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"s8eI2YYtuduMy1Hxa7kJJUeCJoLi5pjEb7FmhpOE5/c=", "user"=>{"email"=>"test#test.nl", "password"=>"[FILTERED]"}, "commit"=>"Inloggen"}
User Load (4.5ms) SELECT "users".* FROM "users" WHERE "users"."email" = 'ed#salves.nl' LIMIT 1
I don't see any differences between the setup of both projects, but how can I make sure the first project also shows the exetended information?
Rails Logger verbosity can be defined with config.log_level in your config/environments files.
You can set it to :debug, :info, :warn, :error, :fatal.
Make sure your first project has the same settings of your second one.
I figured out it had to do with the recent switch to unicorn. Unicorn by default outputs the log to a file instead of STDOUT. So log\development.log is filled with all log messages, but not the terminal screen. To fix this, add this to config/development.rb:
config.logger = Logger.new(STDOUT)
config.logger.level = Logger.const_get(
ENV['LOG_LEVEL'] ? ENV['LOG_LEVEL'].upcase : 'DEBUG'
)
Related
I've got a rails 5 application that is very slow after I boot the server or change a .rb file. Below is my cli output after I booted the server with rails server and loaded a simple page. Also, if I change a model, controller or helper, the server takes about the same time to respond to the next request. After the request is loaded, the pages load normally but that first request after each change can take 30 seconds which adds up quite fast. I have tried setting the following configs in `development (similar questions suggested these changes). Also, I have this development server running on a digital ocean droplet with 4GB of memory.
config.assets.debug = false
config.assets.digest = false
My output:
rails server
=> Booting Puma
=> Rails 5.2.2 application starting in development
=> Run rails server -h for more startup options
Puma starting in single mode...
* Version 3.12.0 (ruby 2.5.3-p105), codename: Llamas in Pajamas
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
Started GET "/treadmill-parts-model-select" for 98.251.169.224 at 2019-04-03
11:51:29 +0000
Cannot render console from 98.251.169.224! Allowed networks: 127.0.0.1, ::1,
127.0.0.0/127.255.255.255
(2.1ms) SET NAMES utf8, ##SESSION.sql_mode = CONCAT(CONCAT(##sql_mode,
',STRICT_ALL_TABLES'), ',NO_AUTO_VALUE_ON_ZERO'),
##SESSION.sql_auto_is_null = 0, ##SESSION.wait_timeout = 2147483
↳ /usr/local/rvm/gems/ruby-2.5.3/gems/activerecord-
5.2.2/lib/active_record/log_subscriber.rb:98
(2.4ms) SELECT 'schema_migrations'.'version' FROM 'schema_migrations' ORDER
BY 'schema_migrations'.'version' ASC
↳ /usr/local/rvm/gems/ruby-2.5.3/gems/activerecord-
5.2.2/lib/active_record/log_subscriber.rb:98
Processing by SearchController#treadmill_model_search as HTML
Rendering search/treadmill_model_search.html.erb within layouts/application
Product Load (113.8ms) SELECT DISTINCT 'products'.'brand' FROM 'products' WHERE 'products'.'product_type' = 'Treadmill' ORDER BY 'products'.'brand' ASC
↳ app/views/search/treadmill_model_search.html.erb:22
Rendered search/treadmill_model_search.html.erb within layouts/application (167.6ms)
Rendered layouts/_header.html.erb (5.8ms)
Rendered layouts/_flash_messages.html.erb (1.1ms)
Rendered layouts/_footer.html.erb (0.5ms)
Completed 200 OK in 18746ms (Views: 18565.0ms | ActiveRecord: 124.7ms)`
Looks like every time your rails server detects a page change it checks to see if their is a migration pending, which will take some time.
#config/environments/development.rb
config.active_record.migration_error = false
could help with that check.
In the development environment your application's code is reloaded on every request. This slows down response time but is perfect for development since you don't have to restart the web server when you make code changes.
As with larger projects you will want to stop rails from pre-loading all the code which isn't needed especially if you are only working on a portion of your project anyways. Also in the environment
#config/environments/development.rb
# Do not eager load code on boot.
config.eager_load = false
You can read more on these environment config settings here
Though the 4GB of memory seems like a red flag if you aren't working on a massive project... might need to look into your initializes and what all your project is loading up on boot.
I just deployed a rails app and I am having an error when I load a page saying:
We're sorry, but something went wrong.
In the production.log I see that message:
Started GET "/" for 128.179.252.130 at 2014-11-30 08:32:28 +0000
Processing by StaticPagesController#home as HTML
Rendered static_pages/home.html.erb within layouts/application (0.4ms)
Rendered layouts/_shim.html.erb (0.0ms)
Rendered layouts/_header.html.erb (2.4ms)
Completed 500 Internal Server Error in 4ms
ActionView::Template::Error (./icons/icon_nameplate.png isn't precompiled):
37:<ul class="dropdown-menu">
38:
39:<li>
40: <%= menu_dropdown('Profile', "./icons/icon_nameplate.png", "Nameplate Icon", current_user) %>
41:</li>
So I believe the error comes from this part of the message:
./icons/icon_nameplate.png isn't precompiled
I searched the internet, found three possible solution, none of which did work:
1. config.assets.compile = true (in production.rb file)
2. config.assets.precompile += %w[*.png *.jpg *.jpeg *.gif] (still in production.rb file)
3. bundle exec rake assets:precompile RAILS_ENV=production
All of this changed absolutely nothing, and the website still shows the same error. So I am turning for you to help.
Thank you very much in advance.
What finally did the trick for me is completely restart the rails app. This is described in the link below.
The recommended version did the trick for me which is:
Create (or update) a file called restart.txt in the tmp folder of your Rails application on the server.
After that no problem at all.
Cheers
I just started giving Unicorn a try (over Thin), and so far I do like the format of the output, except that it doesn't appear to show the post parameters for various requests. I really like this functionality to help debug forms etc....
Unicorn:
20:26:14 web.1 | 127.0.0.1 - - [17/Jan/2012 20:26:14] "POST /basic_simulations HTTP/1.1" 422 24259 0.4838
What I want... (this is from webrick):
Started POST "/basic_simulations" for 127.0.0.1 at 2012-01-17 20:27:22 -0700
Processing by BasicSimulationsController#create as HTML
Parameters: {"utf8"=>"✓",
"authenticity_token"=>"xxxxx", "basic_simulation"=>{"x1706"=>"1"}, "commit"=>"Submit my answers"}
Is there some config option or something of the sort where I can turn this functionality on? Thanks!
UPDATE:
Add this to your config/application.rb file:
config.logger = Logger.new(STDOUT)
More info here
Add this to your config/environments/development.rb file:
config.logger = Logger.new(STDOUT)
More info here
Try this in your site configuration:
log_format postdata $request_body;
access_log /var/log/nginx/postdata.log postdata;
More informations here: Logging POST data from $request_body
If you're using Foreman with a procfile, you can add this line to your Procfile:
devlog: tail -f log/development.log
and it will put the development log to terminal window like webrick.
Somehow this is related but I'm not sure how/why?
Just upgraded from Ruby 1.9.2-p180 to 1.9.2-p290 via RVM's rvm upgrade command...and now my asset pipeline is 'broken'.
During rvm upgrade ... I noticed a bunch of errors for each gemset along lines of:
ERROR: Error running 'rvm gemset pristine' under ,
please read /Users/meltemi/.rvm/log//gemset.pristine.log
I let upgrade continue as there was not much interesting in the gemset.pristine.log... besides, /Users/meltemi/.rvm/log//gemset.pristine.log doesn't (can't?) exist in that exact path? two consecutive '//' in a pathname? Anyway...
Testing a small app and though it launches and appears to run it is not loading any assets (images, css, etc.). Development log has many Not Found errors (see below) about these missing assets even though they exist within app/assets/images and app/assets/stylesheets, etc... ?
Anyone know what's happening here? Seems like pipeline has broken down somehow... As if Rails no longer knows to look for assets in app/assets, perhaps? How can I test/verify/fix/re-activate this 'pipeline'?
$ rails s
=> Booting WEBrick
=> Rails 3.1.0.rc4 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-07-25 23:11:38] INFO WEBrick 1.3.1
[2011-07-25 23:11:38] INFO ruby 1.9.2 (2011-07-09) [x86_64-darwin10.8.0]
[2011-07-25 23:11:38] INFO WEBrick::HTTPServer#start: pid=74881 port=3000
Started GET "/" for 127.0.0.1 at 2011-07-25 23:11:43 -0700
Processing by PostsController#index as HTML
Post Load (0.2ms) SELECT "posts".* FROM "posts" ORDER BY posts.created_at DESC
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.3ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 6
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 5
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 4
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 2
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 1
Rendered posts/index.html.haml within layouts/application (3016.4ms)
Rendered layouts/_header.html.haml (9.7ms)
Completed 200 OK in 3143ms (Views: 3138.2ms | ActiveRecord: 2.9ms)
Started GET "/assets/application.css" for 127.0.0.1 at 2011-07-25 23:11:47 -0700
Served asset /application.css - 404 Not Found (1ms)
ActionController::RoutingError (No route matches [GET] "/assets/application.css"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (1.2ms)
Started GET "/assets/application.js" for 127.0.0.1 at 2011-07-25 23:11:47 -0700
Served asset /application.js - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/application.js"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (0.8ms)
Started GET "/assets/racer-outline.png" for 127.0.0.1 at 2011-07-25 23:11:48 -0700
Served asset /racer-outline.png - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/racer-outline.png"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (3.2ms)
Started GET "/assets/ray.png" for 127.0.0.1 at 2011-07-25 23:11:48 -0700
Served asset /pogo.png - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/ray.png"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (1.2ms)
It seems that version 2.0.0.beta.11 of sprockets broke the assets pipeline. Putting
gem 'sprockets', '= 2.0.0.beta.10'
into your Gemfile seems to fix the problem (it worked for me). Rails seems to automatically use the most recent version of the beta for whatever reason so if you just started your project recently or updated all your gems it probably broke it.
Note that this info isn't mine originally, I got the fix from http://groups.google.com/group/rubyonrails-core/browse_thread/thread/59d8c7813b4d1bbe?pli=1
He explains the problem for ver. 2.0.0.beta.11 but I was using ver. 2.0.0.beta.12 with the same results so it seems that they haven't fixed it yet.
EDIT: It seems that upgrading your rails to 3.1.rc5 also fixes the problem
I ended up just blowing out the whole problematic gemset and starting anew. Lesson learned:
Don't trust rvm upgrade. Install the new Ruby w/in RVM. Then manually rebuild (or bundle install) your gemsets.
When i view my heroku logs on the server (with heroku logs --tail --app myapp) i see something like this:
2011-06-21T14:09:25+00:00 app[web.1]: Started PUT "/reports/19.xml" for 77.89.149.137 at 2011-06-21 07:09:25 -0700
2011-06-21T14:09:25+00:00 heroku[router]: PUT myapp.heroku.com/reports/19.xml dyno=web.1 queue=0 wait=0ms service=7ms status=401 bytes=28
2011-06-21T14:09:26+00:00 heroku[nginx]: PUT /reports/19.xml HTTP/1.1 | 77.89.149.137 | 656 | http | 401
While in my local log i'd see something like this:
Started PUT "/reports/19" for 127.0.0.1 at 2011-06-21 15:27:01 +0100
Processing by ReportsController#update as XML
Parameters: {"report"=>{"workflow_status"=>"3"}, "id"=>"19"}
Person Load (0.9ms) SELECT "people".* FROM "people" WHERE "people"."email" = 'madeupemai#lkklj.com' LIMIT 1
Report Load (0.4ms) SELECT "reports".* FROM "reports" WHERE "reports"."id" = 19 LIMIT 1
DEPRECATION WARNING: Object#returning has been deprecated in favor of Object#tap. (called from update_report at /home/max/work/rails_apps/flamingo_container/flamingo/vendor/plugins/resource_this/lib/resource_this.rb:135)
Creating scope :open. Overwriting existing method Task.open.
Task Load (2.0ms) SELECT "tasks".* FROM "tasks" WHERE "tasks"."id" = 14 LIMIT 1
Completed 200 OK in 1648ms (Views: 568.2ms | ActiveRecord: 3.2ms)
Ie with a lot more information, particularly the params, info from the router, generated sql, any templates rendered etc etc.
Does anyone know how i can get my heroku log to be as verbose as my development one? I've done the following already:
1) Set the log level in the relevant (rails 3) environment file:
config.log_level = :debug
2) Told heroku to use a different logger level, as described on http://devcenter.heroku.com/articles/logging
heroku config:add LOG_LEVEL=DEBUG --app myapp #from CLI
Neither has made any difference...any ideas anyone?
thanks, max
You're essentially wanting to show the SQL / params output in the Heroku logs. You can do this by adding the line shown below to the config block within your production.rb file:
MyAppNameHere::Application.configure do
# add this line
config.logger = Logger.new(STDOUT)
end
By the way, setting the log level to debug just means that Rails.logger.debug will output to the logs when you're on Heroku
In your production.rb add config.log_level = :debug and redeploy. That will give you the same logs as development mode :)
The detailed log you want is generated by the function start_processing in log_subscriber.rb.
action_controller/log_subscriber.rb:
def start_processing(event)
payload = event.payload
params = payload[:params].except(*INTERNAL_PARAMS)
info " Processing by #{payload[:controller]}##{payload[:action]} as #{payload[:formats].first.to_s.upcase}"
info " Parameters: #{params.inspect}" unless params.empty?
end
I checked with rails 3.0.4 in development and production environment. In both environments, we have the detailed logs.
This is an info level log. That's why the debug log level is not changing the output.
I installed the plugin used by heroku rails_log_stdout (Heroku logging) but I still have the desired output.
Right now, I can't test with heroku to find out why you don't have all the logs.
In the heroku example (see Heroku logging, section log retrieval), we don't see the "Processing" and "Parameters" lines. I think that either this method is not called when the app is running on heroku (it is somehow disabled) or heroku skips logs starting with whitespaces. Could you try to log messages starting with whitespaces and see if heroku is showing them?
Rails doesn't generate those logs when in production mode. http://groups.google.com/group/heroku/browse_thread/thread/d778fafedc9a378a
The real problem is actually due to the way Heroku works in conjunction with rails. The right way to solve this is to add: gem 'rails_12factor', group: :production
See https://devcenter.heroku.com/articles/rails-integration-gems for more info on the matter
Looks like the puma server doesn't play well with Heroku. In my project, I tried everything, but it still wouldn't log. I then replaced Puma with Unicorn, and bam, full logs are being shown.