Hi All, as I can see on https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53 the?Rack::CommonLogger used only in development env and in weird evn called "deployment". Any chance to add "production" to this case? Serg Podtynnyi
Serg Podtynnyi <serg at podtynnyi.com> wrote:> Hi All, as I can see on > https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53 > the?Rack::CommonLogger used only in development env and in weird evn > called "deployment". > Any chance to add "production" to this case?Not unless Rack does it, Rack doesn''t recognize "production" in any special way. If you really want it, you can add Rack::CommonLogger to config.ru yourself. Since I was never satisfied with the Rack::CommonLogger logging format, I wrote clogger[1] which offers nginx-like formatting options. [1] http://clogger.rubyforge.org/ - configurable logger for Rack -- Eric Wong
On Aug 16, 2011, at 8:45 AM, Serg Podtynnyi wrote:> Hi All, as I can see on > https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53 > the Rack::CommonLogger used only in development env and in weird evn > called "deployment". > Any chance to add "production" to this case?My wish would be to remove all of the magically added middlewares. Leave the middleware assembly to config.ru. Failing that, my next wish would be to have the magic opt-in. Failing that, my next wish would be for an easy opt-out. It is maddening to debug an error in your app that causes the ShowExceptions middleware to crash, masking your actual problem. -john
John Fieber <jfieber at adobe.com> wrote:> On Aug 16, 2011, at 8:45 AM, Serg Podtynnyi wrote: > > Hi All, as I can see on > > https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53 > > the Rack::CommonLogger used only in development env and in weird evn > > called "deployment". > > Any chance to add "production" to this case? > > My wish would be to remove all of the magically added middlewares. > Leave the middleware assembly to config.ru.If you can convince Rack upstream, Unicorn will follow. I dislike magic middlewares, too, but I try to follow Rack to minimize the differences for people using unicorn (and also switching between "rackup" and unicorn).> Failing that, my next wish would be to have the magic opt-in. Failing > that, my next wish would be for an easy opt-out. It is maddening to > debug an error in your app that causes the ShowExceptions middleware > to crash, masking your actual problem.I always set RACK_ENV=none for any services I run so nothing gets added automatically. -- Eric Wong
On Tue, Aug 16, 2011 at 9:30 PM, Eric Wong <normalperson at yhbt.net> wrote:> Serg Podtynnyi <serg at podtynnyi.com> wrote: >> Hi All, as I can see on >> https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53 >> the?Rack::CommonLogger used only in development env and in weird evn >> called "deployment". >> Any chance to add ?"production" to this case? > > Not unless Rack does it, Rack doesn''t recognize "production" in any > special way. > > If you really want it, you can add Rack::CommonLogger to config.ru > yourself. > > Since I was never satisfied with the Rack::CommonLogger logging format, > I wrote clogger[1] which offers nginx-like formatting options. > > > > [1] http://clogger.rubyforge.org/ - configurable logger for Rack >I am asking about this default values because by the convention production env is 99% "production", but in the code I see "deployment", so most of the people that are using unicorn have bogus logs on production. Thanks for clogger suggestion. PS Any idea of how to have some kind of useful information when master process kills workers by timeout? We just monkey patched Unicorn::HttpParser read method like this https://gist.github.com/1151164 to get more info. Is there a better way to do this?
Serg Podtynnyi <serg at podtynnyi.com> wrote:> I am asking about this default values because by the convention > production env is 99% "production", but in the code I see > "deployment", so most of the people that are using unicorn have bogus > logs on production. Thanks for clogger suggestion.Yeah, as I explained in the other post, I''ve always tried to base as many defaults off Rack defaults so people have less trouble switching from/to Unicorn. I''m quite happy with how clogger works, hopefully we find more happy users :) (I don''t like relying on unicorn to promote clogger, though. clogger should be able to stand on its own since it works with any Rack server).> Any idea of how to have some kind of useful information when master > process kills workers by timeout?It''s not possible to know what a worker is doing since SIGKILL isn''t trappable. The master killing workers should only be a last resort that''ll let you limp by until you can have a proper fix. The the rest of the app should have local timeouts for all non-deterministic calls.> We just monkey patched Unicorn::HttpParser read method like this > https://gist.github.com/1151164 to get more info. Is there a better > way to do this?There isn''t any difference between that and having Rack middleware at the top of your stack (clogger logs at the end, and if you have things like $body_bytes_sent it even wraps the response body) class LogBefore < Struct.new(:app) def call(env) env["rack.logger"].debug env["REQUEST_PATH"] end end --------- config.ru --------- use LogBefore use ... use ... use ... run YourApp.new ----------------------------- -- Eric Wong
Eric Wong <normalperson at yhbt.net> wrote:> The the rest of the app should have local timeouts for all > non-deterministic calls.If you''re lazy, maybe the following middleware works, too, I haven''t ever needed it but wrote (and later rewrote it) as a proof-of-concept: http://bogomips.org/rainbows.git/tree/lib/rainbows/thread_timeout.rb It should work with bare Unicorn if you remove the "Rainbows" references and the negative threshold handling in "initialize". If somebody wants I can split it into it''s own gem (should work with WEBrick, Mongrel, Passenger, and maybe Thin), too). Unlike the Timeout library in Ruby stdlib, this doesn''t allow nested timeout {} calls so it''s simpler/possibly-safer in this regard... I even posted a request-for-review for the middleware on ruby-talk but didn''t get any responses: http://mid.gmane.org/20110421232615.GA27468 at dcvr.yhbt.net -- Eric Wong