Unicorn is an HTTP server for Rack applications designed to only serve
fast clients on low-latency, high-bandwidth connections and take
advantage of features in Unix/Unix-like kernels. Slow clients should
only be served by placing a reverse proxy capable of fully buffering
both the the request and response in between Unicorn and slow clients.
* http://unicorn.bogomips.org/
* mongrel-unicorn at rubyforge.org
* git://git.bogomips.org/unicorn.git
Changes:
Thanks to Augusto Becciu for finding a bug in the HTTP parser
that caused a TypeError (and 500) when a rare client set the
"Version:" header which conflicts with the HTTP_VERSION header
we parse in the first line of the request[1].
Horizontal tabs are now allowed as leading whitespace in header
values as according to RFC 2616 as pointed out by
I?aki Baz Castillo[2].
Taking a hint from Rack 1.1, the "logger" configuration
parameter no longer requires a "close" method. This means some
more Logger replacements may be used.
There''s a new, optional, Unicorn (and maybe Passenger)-only
middleware, Unicorn::OobGC[2] that runs GC outside of the normal
request/response cycle to help out memory-hungry applications.
Thanks to Luke Melia for being brave enough to test and report
back on my big_app_gc.rb monkey patch[3] which lead up to this.
Rails 3 (beta) support:
Using "unicorn" is still recommended as Rails 3 comes with
a config.ru, but "unicorn_rails" is cleaned up a bit and
*should* work as well as "unicorn" out-of-the-box. Feedback
is much appreciated.
Rubinius updates:
USR2 binary upgrades are broken due to
{TCPServer,UNIXServer}.for_fd[5][6] being broken
(differently).
Repeatedly hitting the server with signals in a tight
loop is unusual and not recommended[7].
There are some workarounds and general code cleanups for other
issues[8], as well but things should generally work unless you
need USR2 upgrades. Feedback and reports would be greatly
appreciated as usual.
MRI support:
All tests (except old Rails) run and pass under 1.9.2-preview3.
1.8.7 and 1.9.1 work well as usual and will continue to be
supported indefinitely.
Lets hope this is the last release before 1.0. Please report
any issues on the mailing list[9] or email us privately[a].
Don''t send HTML mail.
[1] - http://mid.gmane.org/AANLkTimuGgcwNAMcVZdViFWdF-UcW_RGyZAue7phUXps at
mail.gmail.com
[2] - http://mid.gmane.org/i2xcc1f582e1005070651u294bd83oc73d1e0adf72373a at
mail.gmail.com
[3] - http://unicorn.bogomips.org/Unicorn/OobGC.html
[4] - http://unicorn.bogomips.org/examples/big_app_gc.rb
[5] - http://github.com/evanphx/rubinius/issues/354
[6] - http://github.com/evanphx/rubinius/issues/355
[7] - http://github.com/evanphx/rubinius/issues/356
[8] - http://github.com/evanphx/rubinius/issues/347
[9] - mailto:mongrel-unicorn at rubyforge.org
[a] - mailto:unicorn at bogomips.org
--
Eric Wong
Hello! One question: it''s a normal state if i start rails app without preload and after Gem.refresh all works go down by exception from Ge.refresh and master process all time trying reup they. And it''s go to recursion. I know it''s issue of people who start app, but in any case it''s must be exception for stop of master process. Is i check code when starts workers and if we have preload_app false method run build_app!. If we have preload_app true - then we check it before start worker.
Alexander Simonov <alex at simonov.me> wrote:> > Hello! > > One question: it''s a normal state if i start rails app without preload > and after Gem.refresh all works go down by exception from Ge.refresh > and master process all time trying reup they. And it''s go to > recursion. I know it''s issue of people who start app, but in any case > it''s must be exception for stop of master process. Is i check code > when starts workers and if we have preload_app false method run > build_app!. If we have preload_app true - then we check it before > start worker.Hi Alexander, I hope I''m understanding you correctly, so you want the master process to die if you''ve misdeployed or misconfigured your app? This is one of those sharp edges of Unicorn that might be pointless to protect against with preload_app=false... The general rule is that you shouldn''t be mucking around with Gem (or any other library) installations on a production server unless you''re deploying. And whenever you''re deploying, you would always be checking to see you''ve deployed correctly anyways, so you can detect any screwups in the installation/deployment. Let me know if that makes sense. -- Eric Wong
On Jun 9, 2010, at 9:22 PM, Eric Wong wrote:> Alexander Simonov <alex at simonov.me> wrote: >> >> Hello! >> >> One question: it''s a normal state if i start rails app without preload >> and after Gem.refresh all works go down by exception from Ge.refresh >> and master process all time trying reup they. And it''s go to >> recursion. I know it''s issue of people who start app, but in any case >> it''s must be exception for stop of master process. Is i check code >> when starts workers and if we have preload_app false method run >> build_app!. If we have preload_app true - then we check it before >> start worker. > > Hi Alexander, > > I hope I''m understanding you correctly, so you want the master process > to die if you''ve misdeployed or misconfigured your app?yes, something like this.> > This is one of those sharp edges of Unicorn that might be pointless > to protect against with preload_app=false... > > The general rule is that you shouldn''t be mucking around with Gem (or > any other library) installations on a production server unless you''re > deploying. And whenever you''re deploying, you would always be checking > to see you''ve deployed correctly anyways, so you can detect any screwups > in the installation/deployment. > > Let me know if that makes sense.Ok. But the main thing is the master process goes to recursion restart of workers if they return exit or exception.May be add the counter? For example, 10 times we trying to respawn working process and after stop master. I think it makes sense.
Alexander Simonov <alex at simonov.me> wrote:> On Jun 9, 2010, at 9:22 PM, Eric Wong wrote: > > Alexander Simonov <alex at simonov.me> wrote: > >> > >> Hello! > >> > >> One question: it''s a normal state if i start rails app without preload > >> and after Gem.refresh all works go down by exception from Ge.refresh > >> and master process all time trying reup they. And it''s go to > >> recursion. I know it''s issue of people who start app, but in any case > >> it''s must be exception for stop of master process. Is i check code > >> when starts workers and if we have preload_app false method run > >> build_app!. If we have preload_app true - then we check it before > >> start worker. > > > > Hi Alexander, > > > > I hope I''m understanding you correctly, so you want the master process > > to die if you''ve misdeployed or misconfigured your app? > > yes, something like this. > > > > > This is one of those sharp edges of Unicorn that might be pointless > > to protect against with preload_app=false... > > > > The general rule is that you shouldn''t be mucking around with Gem (or > > any other library) installations on a production server unless you''re > > deploying. And whenever you''re deploying, you would always be checking > > to see you''ve deployed correctly anyways, so you can detect any screwups > > in the installation/deployment. > > > > Let me know if that makes sense. > > Ok. But the main thing is the master process goes to recursion restart > of workers if they return exit or exception.May be add the counter? > For example, 10 times we trying to respawn working process and after > stop master. I think it makes sense.It''d have to be a time-aware counter, because sometimes slightly broken _will_ exit/die 10 times over the period of an hour. But the site can still be making enough money with 99.8% successful service and not care about spending time/resources fixing the last 0.2% :) But even with a proper time-aware counter, the app is still broken at deploy time. So I don''t believe there is much point in adding more code just to exit the process when the proper solution is for the user to _fix_ the app. And again (I seem to remember saying this months ago), any time you''re deploying, you should be paying extra attention to the app anyways. That means testing with actual HTTP requests, not just seeing of the process is up. Just having a running process serving error pages is equally worthless as not running the server at all. -- Eric Wong
On Jun 10, 2010, at 10:38 AM, Eric Wong wrote:> It''d have to be a time-aware counter, because sometimes slightly broken > _will_ exit/die 10 times over the period of an hour. But the site can > still be making enough money with 99.8% successful service and not > care about spending time/resources fixing the last 0.2% :) > > But even with a proper time-aware counter, the app is still broken at > deploy time. So I don''t believe there is much point in adding more code > just to exit the process when the proper solution is for the user to > _fix_ the app. > > And again (I seem to remember saying this months ago), any time you''re > deploying, you should be paying extra attention to the app anyways. > That means testing with actual HTTP requests, not just seeing of the > process is up. Just having a running process serving error pages is > equally worthless as not running the server at all.Hm.. It''s makes sense. But much better if it will be writing in the documentation for the future. Thank you!
Alexander Simonov <alex at simonov.me> wrote:> On Jun 10, 2010, at 10:38 AM, Eric Wong wrote: > > And again (I seem to remember saying this months ago), any time you''re > > deploying, you should be paying extra attention to the app anyways. > > That means testing with actual HTTP requests, not just seeing of the > > process is up. Just having a running process serving error pages is > > equally worthless as not running the server at all. > > Hm.. It''s makes sense. > But much better if it will be writing in the documentation for the future.Here''s what I''ve pushed out, let me know if everything makes sense. I think I''ll release 0.991.0 in a little bit.>From f9baab18705218dae4c37c2c92d1ceea151bba8e Mon Sep 17 00:00:00 2001From: Eric Wong <normalperson at yhbt.net> Date: Thu, 10 Jun 2010 17:57:08 -0700 Subject: [PATCH] docs: hopefully clarify preload_app=false behavior While we''re at it, inform people of why they might use a symlink --- SIGNALS | 7 ++++++- lib/unicorn/configurator.rb | 21 ++++++++++++++++++--- 2 files changed, 24 insertions(+), 4 deletions(-) diff --git a/SIGNALS b/SIGNALS index be96892..8851775 100644 --- a/SIGNALS +++ b/SIGNALS @@ -14,7 +14,12 @@ Unicorn and nginx. will also pick up any application code changes when restarted. If "preload_app" is true, then application code changes will have no effect; USR2 + QUIT (see below) must be used to load newer code in - this case. + this case. When reloading the application, +Gem.refresh+ will + be called so updated code for your application can pick up newly + installed RubyGems. It is not recommended that you uninstall + libraries your application depends on while Unicorn is running, + as respawned workers may enter a spawn loop when they fail to + load an uninstalled dependency. * INT/TERM - quick shutdown, kills all workers immediately diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb index 71c7a8a..533e0ed 100644 --- a/lib/unicorn/configurator.rb +++ b/lib/unicorn/configurator.rb @@ -311,7 +311,22 @@ module Unicorn # # In addition to reloading the unicorn-specific config settings, # SIGHUP will reload application code in the working - # directory/symlink when workers are gracefully restarted. + # directory/symlink when workers are gracefully restarted when + # preload_app=false (the default). As reloading the application + # sometimes requires RubyGems updates, +Gem.refresh+ is always + # called before the application is loaded (for RubyGems users). + # + # During deployments, care should _always_ be taken to ensure your + # applications are properly deployed and running. Using + # preload_app=false (the default) means you _must_ check if + # your application is responding properly after a deployment. + # Improperly deployed applications can go into a spawn loop + # if the application fails to load. While your children are + # in a spawn loop, it is is possible to fix an application + # by properly deploying all required code and dependencies. + # Using preload_app=true means any application load error will + # cause the master process to exit with an error. + def preload_app(bool) case bool when TrueClass, FalseClass @@ -344,9 +359,9 @@ module Unicorn set_path(:stdout_path, path) end - # sets the working directory for Unicorn. This ensures USR2 will + # sets the working directory for Unicorn. This ensures SIGUSR2 will # start a new instance of Unicorn in this directory. This may be - # a symlink. + # a symlink, a common scenario for Capistrano users. def working_directory(path) # just let chdir raise errors path = File.expand_path(path) -- Eric Wong
On Jun 11, 2010, at 4:27 AM, Eric Wong wrote:> Alexander Simonov <alex at simonov.me> wrote: >> On Jun 10, 2010, at 10:38 AM, Eric Wong wrote: >>> And again (I seem to remember saying this months ago), any time you''re >>> deploying, you should be paying extra attention to the app anyways. >>> That means testing with actual HTTP requests, not just seeing of the >>> process is up. Just having a running process serving error pages is >>> equally worthless as not running the server at all. >> >> Hm.. It''s makes sense. >> But much better if it will be writing in the documentation for the future. > > Here''s what I''ve pushed out, let me know if everything makes > sense. I think I''ll release 0.991.0 in a little bit.Ok! Thank you! Good. After release I will update golden_brindle too :)> >> From f9baab18705218dae4c37c2c92d1ceea151bba8e Mon Sep 17 00:00:00 2001 > From: Eric Wong <normalperson at yhbt.net> > Date: Thu, 10 Jun 2010 17:57:08 -0700 > Subject: [PATCH] docs: hopefully clarify preload_app=false behavior > > While we''re at it, inform people of why they might use > a symlink
Eric Wong <normalperson at yhbt.net> wrote:> Rubinius updates: > but things should generally work unless you > need USR2 upgrades. Feedback and reports would be greatly > appreciated as usual.Log rotation for $stderr and $stdout (but not other paths) are broken under Rubinius, too. I only discovered this while running the Rainbows! integration tests. ref: http://github.com/evanphx/rubinius/issues/360 -- Eric Wong