I have been using Thin to run my ruby Sinatra applications but I am now switching over to Puma. Thin creates its own log log/thin.log which I use. I noticed that Puma doesn't produce a log file (not that I can see). I have tried googling for documentation around this but not really found anything.
I was wondering if/how you can specify a log path in Puma.
Any help would be much appreciated.
Alex
Check the example config.rb as recommended on the repo's README.
As shown there:
# Redirect STDOUT and STDERR to files specified. The 3rd parameter
# (“append”) specifies whether the output is appended, the default is “false”.
stdout_redirect '/u/apps/lolcat/log/stdout', '/u/apps/lolcat/log/stderr'
stdout_redirect '/u/apps/lolcat/log/stdout', '/u/apps/lolcat/log/stderr', true
Related
So check this out: it appears as though, upon running bundle exec rspec, there's a race between jekyll serve and puma/rspec's boot up. Sometimes I run the command, and my tests run fine. Other times, I get the error for each of my spec files: cannot load such file -- /path/to/project/sitename_jekyll/_layouts/spec/form_spec.rb which is interesting cause that's not where my spec files are located. They're in /path/to/project/sitename_jekyll/spec/form_spec.rb.
What's crazy is that I can literally just re-run the command over and over and over again and sometimes it'll go through and run the spec tests in the correct location, and sometimes it'll look for them in _layouts and error out. It probably runs correctly maybe once out of ever three or five attempts. All the other times I get the following errors:
Here's what my spec_helper.rb looks like: https://gist.github.com/johnhutch/2cddfafcde0485ff021501d5696c0c2d
And here's an example test file:
https://gist.github.com/johnhutch/a35d15c170f5fd9ca07998bf035d111d
My .rspec only contains two lines:
--color
--require spec_helper
And here's the output, both successful and unsuccesful, back to back:
https://gist.github.com/johnhutch/7927d609170ef5c70a595735502b128d
HEEELLLLLP!
This sounds like jekyll is changing the current directory while building the site, which since it is being run in a thread also affects the tests RSpec is trying to run (See https://bugs.ruby-lang.org/issues/9785 for why Dir.chdir is not threadsafe) - leading to attempts to load things from incorrect locations.
A potential solution to this would be to wait for the Jekyll site to be built before actually running your tests. A comment in your spec_helper seems to state that someone thought passing force_build: true would do this but from a quick perusal of the jekyll-rack code I don't think that's true and you actually need to wait for compiling? to return false (v 0.5) (complete? to return true in the current master branch) to ensure building has finished (as well as passing force_build). This could either be done in a loop sleeping and checking (simpler)
sleep 0.1 while <jekyll app>.compiling?
or (if using the master branch) via the mutex/conditional Rack::Jekyll exposes like in its test suite - https://github.com/adaoraul/rack-jekyll/blob/master/test/helper.rb#L49
Note: Also check my comment about your tests that aren't actually testing anything.
As per Thomas Walpole's super helpful responses this ended up working:
sleep 0.1 while Capybara.app.compiling?
inserted right after:
51 Capybara.app = Rack::Jekyll.new(force_build: true)
in my spec_helper.rb
Thanks again, Thomas!
I am using Bluemix Ruby buildpack out of the box.
I add some puts lines in my main *.rb file but nothing appears when tailing logs:
cf logs myapp
Searching the docs, I found this post at developerWorks where it is recommended to set runtime into development mode.
I have tried with:
cf set-env myapp RAILS_ENV development
and also adding to the code:
ENV['RAILS_ENV'] = 'development'
but nothing appears in the logs.
Also tried Sinatra options (after changing the code) with same results:
set :environment, :development
set :logging, true
An interesting thing, is that if I stop the app, then all my puts appears after the stacktrace of the FATAL SignalException: SIGTERM error. It seems like a buffer flush contention or anything like that?
Any advice? Thanks!
You can add the following line to your config.ru file. This will disable buffering to stdout and allows your puts commands to stdout to appear correctly in the log output.
$stdout.sync = true
See the answer at What STDOUT.sync = true means? for more details about how puts buffers.
Not Sure but have you tried the following links
https://developer.ibm.com/answers/questions/21548/debugging-a-ruby-app-in-bluemix-with-puts-or-print-statements-written-to-the-log-is-it-possible.html
http://www.ibm.com/developerworks/aix/library/au-unix-commandline/
So, I want to have completely custom logging for my sinatra application, but I can't seem to disable the Rack::CommonLogger.
As per the sinatra docs all I should need to do is add the following line (tried setting it to false as well):
set :logging, nil
to my configuration. This does not work however, and I still receive the Apache-like log messages in my terminal. So the only solution I've found so far is to monkey patch the damn thing.
module Rack
class CommonLogger
def call(env)
# do nothing
#app.call(env)
end
end
end
Anyone got any ideas if it's possible to disable this without restorting to such matters?
I monkey patched the log(env, status, header, began_at) function, which is what gets called by rack to produce the apache style logs. We use jruby with logback so we have no use for all the custom logging that seems to pervade the ruby ecosystem. I suspect fishwife is initalizing the CommonLogger, which might explain why all my attempts to disable it or to configure it with a custom logger fail. Probably puma does something similar. I actually had two instances at one point. One logging with my custom logger (yay) and another one still doing its silly puts statements on stderr. I must say, I'm pretty appalled with the logging hacks in the rack ecosystem. Seems somebody needs a big cluebat to their heads.
Anyway, putting this in our config.ru works for us:
module Rack
class CommonLogger
def log(env, status, header, began_at)
# make rack STFU; our logging middleware takes care of this
end
end
end
In addition to that, I wrote my own logging middleware that uses slf4j with a proper MDC so we get more meaningful request logging.
Puma adds logging middleware to your app if you are in development mode and haven’t set the --quiet option.
To stop Puma logging in development, pass the -q or --quiet option on the command line:
puma -p 3001 -q
or if you are using a Puma config file, add quiet to it.
Rack includes a few middlewares by default when you rackup your application. It is defined in this file.
By default, as you mention, the logging middleware is enabled.
To disable it, just pass the option --quiet to rackup:
rackup --quiet
And the default loggin middleware will not be enabled.
Then, you can enable your own logging middleware without pollution by the default logger (named CommonLogger).
You can also add #\ --quiet to the top of your config.ru file to avoir always typing --quiet, but this behaviour is now deprecated.
It's probably not Sinatra what is writing to STDOUT or STDERR, but your webserver. Puma can be started with -q (quiet) option as noted by #matt. When using webrick make sure the AccessLog configuration variable is an empty array, otherwise it will also be logged on your standard output.
Disabling echo from webrick
This is one of the top results. So this probably more of a message to my future self the next time I'm annoyed to death about sinatra/puma not shutting up. But to actually get a silent start up:
class MyApp < Sinatra::Base
configure do
set :server, :puma
set :quiet, true
set :server_settings, Silent: true
end
end
I've got a rails 3.1 app deployed on Heroku Cedar. I'm having a problem with the logging. The default rails logs are working just fine, but when I do something like:
logger.info "log this message"
In my controller, Heroku doesn't log anything. When I deploy my app I see the heroku message "Injecting rails_log_stdout" so I think calling the logger should work just fine. Puts statements end up in my logs. I've also tried other log levels like logger.error. Nothing works. Has anyone else seen this?
MBHNYC's answer works great, but it makes it difficult to change the log level in different environments without changing the code. You can use this code in your environments/production.rb to honor an environment variable as well as have a reasonable default:
# https://github.com/ryanb/cancan/issues/511
config.logger = Logger.new(STDOUT)
config.logger.level = Logger.const_get((ENV["LOG_LEVEL"] || "INFO").upcase)
Use this command to set a different log level:
heroku config:set LOG_LEVEL=error
I was just having the same issue, solved by using the technique here:
https://github.com/ryanb/cancan/issues/511
Basically, you need to specify the logger outputs to STDOUT, some gems interfere with the logger and seem to hijack the functionality (cancan in my case).
For the click lazy, just put this in environments/production.rb
config.logger = Logger.new(STDOUT)
config.log_level = :info
As of the moment, it looks like heroku injects these two plugins when building the slug:
rails_log_stdout - https://github.com/ddollar/rails_log_stdout
rails3_server_static_assets - https://github.com/pedro/rails3_serve_static_assets
Anything sent to the pre-existing Rails logger will be discarded and will not be visible in logs. Just adding this for completeness for anyone else who ends up here.
The problem, as #MBHNYC correctly addressed, is that your logs are not going to STDOUT.
Instead of configuring manually all that stuff, Heroku provides a gem that does this all for you.
Just put
gem 'rails_12factor', group: :production
in your Gemfile, bundle, and that's it!
NOTE: This works both for Rails 3 and 4.
Source: Rails 4 on Heroku
I would like to make HTTP requests from Rails code running on top of JRuby.
How can I make it to re-use http.proxyHost, http.proxyPort and http.nonProxyHosts settings, given to JVM running it ?
To pass JVM flags through JRuby, use -J.... In this case:
jruby -J-Dhttp.proxyHost=foo -J-Dhttp.proxyPort=1234 -J-Dhttp.nonProxyHosts="*.bar.com" ...
This is explained in JRuby's help text.
-J[java option] pass an option on to the JVM (e.g. -J-Xmx512m)
use --properties to list JRuby properties
run 'java -help' for a list of other Java options
I have had the same issue. I found that java or net::http doesn't obey the nonProxyHosts option. The best way to get around this is to modify the ENV_JAVA settings to account for this.
The steps I took to ensure nonProxyHosts was used were the following:
1) JAVA_OPTS="-Dhttp.proxyHost=192*** -Dhttp.proxyPort=1234 -Dhttp.nonProxyHosts=local|127.0.0.1"
OR
1) JRUBY_OPTS="-J-Dhttp.proxyHost=192*** -J-Dhttp.proxyPort=1234 -J-Dhttp.nonProxyHosts=local|127.0.0.1"
Keep in mind that at least for java1.7 the nonProxyHosts should not have quotations see here.
Now I find that either net::http or java itself doesn't actually honour the nonProxyHosts option.
However you can get around this by doing the following in JRuby
a = URI("http://someurl")
Net::HTTP.new(a).proxy?.should == true
regex = /$#{ENV_JAVA["http.nonProxyHosts"]}/ #dollar needed to behave as expected
if a.hostname.match(regex)
ENV_JAVA["http.proxyHost"]=nil
end
Net::HTTP.new(a).proxy?.should == false
Hope that helps.