For security reasons I don't wish to have Sinatra print every URL its requested in standard output, I've tried using set :logging, false as suggested in this answer using:
class SweetAppName< Sinatra::Base
set :show_exceptions, false
set :environment, :production
set :logging, false
However when I run the app using rackup and thin, I still see the request logged to the terminal:
127.0.0.1 - - [26/May/2015:09:32:34 -0700] "GET /not-a-real-url HTTP/1.0" 404 - 0.0452
How can I turn these off?
If you start your app with rackup, Rack will add some middleware, including logging. You can prevent this by using the quiet option (-q or --quiet) to rackup, i.e. from the command line:
$ rackup -q
You can include this option in your config.ru if you want, so you don’t have to remember typing it every time you start your app. The first line that starts with #\ is parsed as options, so you can have a config.ru like this:
#\ --quiet
# other middleware etc...
run SweetAppName
If you use the classic Sinatra app style you will need to add the set :logging, false line, otherwise Sinatra will add its own logging. With the modular style (like you are using in the question) this setting defaults to false so you shouldn’t need it.
Related
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/
I want to override the normal sinatra internal server error so it instead displays an erb file.
So far I have this:
set :show_exceptions, :after_handler
error 400..510 do
erb :error
end
But it doesn't work... any ideas?
This is most probably because you run it in the development mode. Not sure if you can suppress it there. But since most time it's only important to show this error pages in production you can simply set RACK_ENV to production.
For example if you start your app like this:
bundle exec ruby app.rb
Just add RACK_ENV
RACK_ENV=production bundle exec ruby app.rb
Most times on a Production server this is set anyway, so there is no need to set it explicit.
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'm new to ruby, learning Sinatra. While creating a Sinatra site by requiring 'sinatra' and setting up the routes directly under is pretty easy and rather well documented, creating an application by requiring 'sinatra/base' and writing a class that inherits from 'Sinatra::Base', while still relatively easy, is very poorly documented (maybe because it's a pretty recent feature of Sinatra).
And that's exactly what I am doing. I am not having too much trouble on the Sinatra part, however I am having a bit of trouble on the rackup/thin/server part. Apparently there are two ways to deploy the application: using Sinatra itself (using the run! method) and using a rackup file (typically config.ru).
Using Sinatra's run! method is extremely intuitive and works like a charm, but apparently it doesn't work if I want to deploy my app on heroku. As a matter of fact, almost all the Sinatra apps that I have encountered on GitHub use a config.ru file.
Using a rackup file might be equally intuitive, but I can't manage to understand how to pass options from the Sinatra app to the server (ir: the port). I tried to merge options to rackup's default options array:
MyApp::App.default_options.merge!(
:run => false,
:env => :production,
:port => 4567
)
run MyApp::App
by adding options directly to the app:
MyApp::App.set :port, 4567
MyApp::App.set :run, false
MyApp::App.set :env, :production
run MyApp::App
by setting options from within the application class:
module MyApp
class App < Sinatra::Base
set :port, 4567
set :run, false
set :env, :production
# ...
# config.ru
require 'app'
run MyApp::App
All the methods above failed, either by showing error messages or by just not taking any of the options into consideration. So is there any way to pass options to rackup/thin/the sever via a Sinatra app when using a rackup file? Or the options in questions should be passed directly to rackup/thin/the sever via command-line options?
As a reference to the problem, here is the little Sinatra application I am building: https://github.com/AzizLight/Wiki/
You're actully going to pass options to thin on the command line directly or via a configuration file. See all options:
$ thin -h
For production, use a configuration file:
$ thin -C thin-production.yml -R config.ru start
Here is an example thin-production.yml file:
---
address: localhost
port: 3020
servers: 4
max_conns: 1024
max_persistent_conns: 512
timeout: 30
environment: production
pid: tmp/pids/thin-production.pid
log: log/thin-production.log
daemonize: true
I know I'm resurrecting an ancient question here, but I came across another useful solution not yet mentioned. As stated in this rack wiki tutorial:
the first line starting with #\ is treated as if it was options, allowing rackup arguments to be specified in the config file.
So if you wanted to set your host to 0.0.0.0 and port to 5656, you would add the following line to the beginning of your config.ru file:
#\ -o 0.0.0.0 -p 5656
I'm deploying a Sinatra app using passenger. The deployed app is working, but not entirely: some paths work fine, others simply render a blank page. I can't seem to find any major differences between the routes that work and the routes that don't, and I can't seem to track down any errors..
Handlers
I have defined the not_found and error handlers as follows:
not_found do
'404. Bummer!'
end
error do
'Nasty error: ' + env['sinatra.error'].name
end
These work fine on my local machine, both in development and production, but I never see these come up on the server.
Apache Logs
When I tail Apache's access.log and hit one of the broken paths, I see a 500:
helpers [27/Oct/2009:15:54:59 -0400] "GET /admin/member_photos/photos HTTP/1.1" 500 20 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3"
rack_hoptoad
I've also installed and configured rack_hoptoad middleware in my config.ru, but no exceptions are making it to hoptoad.
# Send exceptions to hoptoad
require 'rack_hoptoad'
use Rack::HoptoadNotifier, 'MY_API_KEY'
logging
I've set up logging like so..
set :raise_errors => true
set :logging, true
log = File.new("log/sinatra.log", "a+")
STDOUT.reopen(log)
STDERR.reopen(log)
require 'logger'
configure do
LOGGER = Logger.new("log/sinatra.log")
end
helpers do
def logger
LOGGER
end
end
This setup lets me call logger.info within my routes, which works locally and on the server for the working routes, but the broken paths don't get far enough to call logger.info.
What to do?
Any ideas as to how I can see what's causing the 500 errors? Thanks for any help!
I would try using the Rack::ShowExceptions middleware to try and trace out the problem. In your config.ru add these two lines before the run call:
require 'rubygems'
require 'your-app'
use Rack::ShowExceptions
run YourApp
That should catch and display the backtrace for any exceptions occurring in Rack or in your app. That should give you more details to work with, at least that would be the hope.
Maybe there's something wrong with your log setup?
Redirect STDERR when running the Sinatra server so you can read it. Like:
ruby myapp.rb -p 1234 > log/app.log 2>&1
Thanks for the responses, but I didn't end up needing to use them. I was originally deploying the app in a sub-URI configuration. When I deployed the app to it's own subdomain instead, the problems went away.
So.. I'm not really sure what the problem was, but getting rid of this line is my Apache configuration for the site is what resolved things:
Redirect permanent / https://www.example.org/admin/member_photos/