boourns-unicorn 4.4.1

data/Rakefile

@@ -0,0 +1,97 @@
+# -*- encoding: binary -*-
+autoload :Gem, 'rubygems'
+require 'wrongdoc'
+
+cgit_url = Wrongdoc.config[:cgit_url]
+git_url = Wrongdoc.config[:git_url]
+
+desc "post to RAA"
+task :raa_update do
+  require 'net/http'
+  require 'net/netrc'
+  rc = Net::Netrc.locate('unicorn-raa') or abort "~/.netrc not found"
+  password = rc.password
+
+  s = Gem::Specification.load('unicorn.gemspec')
+  desc = [ s.description.strip ]
+  desc << ""
+  desc << "* #{s.email}"
+  desc << "* #{git_url}"
+  desc << "* #{cgit_url}"
+  desc = desc.join("\n")
+  uri = URI.parse('http://raa.ruby-lang.org/regist.rhtml')
+  form = {
+    :name => s.name,
+    :short_description => s.summary,
+    :version => s.version.to_s,
+    :status => 'stable',
+    :owner => s.authors.first,
+    :email => s.email,
+    :category_major => 'Library',
+    :category_minor => 'Web',
+    :url => s.homepage,
+    :download => "http://rubyforge.org/frs/?group_id=1306",
+    :license => "Ruby's",
+    :description_style => 'Plain',
+    :description => desc,
+    :pass => password,
+    :submit => "Update",
+  }
+  res = Net::HTTP.post_form(uri, form)
+  p res
+  puts res.body
+end
+
+desc "post to FM"
+task :fm_update do
+  require 'tempfile'
+  require 'net/http'
+  require 'net/netrc'
+  require 'json'
+  version = ENV['VERSION'] or abort "VERSION= needed"
+  uri = URI.parse('https://freecode.com/projects/unicorn/releases.json')
+  rc = Net::Netrc.locate('unicorn-fm') or abort "~/.netrc not found"
+  api_token = rc.password
+  _, subject, body = `git cat-file tag v#{version}`.split(/\n\n/, 3)
+  tmp = Tempfile.new('fm-changelog')
+  tmp.puts subject
+  tmp.puts
+  tmp.puts body
+  tmp.flush
+  system(ENV["VISUAL"], tmp.path) or abort "#{ENV["VISUAL"]} failed: #$?"
+  changelog = File.read(tmp.path).strip
+
+  req = {
+    "auth_code" => api_token,
+    "release" => {
+      "tag_list" => "Experimental",
+      "version" => version,
+      "changelog" => changelog,
+    },
+  }.to_json
+
+  if ! changelog.strip.empty? && version =~ %r{\A[\d\.]+\d+\z}
+    Net::HTTP.start(uri.host, uri.port, :use_ssl => true) do |http|
+      p http.post(uri.path, req, {'Content-Type'=>'application/json'})
+    end
+  else
+    warn "not updating freshmeat for v#{version}"
+  end
+end
+
+# optional rake-compiler support in case somebody needs to cross compile
+begin
+  mk = "ext/unicorn_http/Makefile"
+  if File.readable?(mk)
+    warn "run 'gmake -C ext/unicorn_http clean' and\n" \
+         "remove #{mk} before using rake-compiler"
+  elsif ENV['VERSION']
+    unless File.readable?("ext/unicorn_http/unicorn_http.c")
+      abort "run 'gmake ragel' or 'make ragel' to generate the Ragel source"
+    end
+    spec = Gem::Specification.load('unicorn.gemspec')
+    require 'rake/extensiontask'
+    Rake::ExtensionTask.new('unicorn_http', spec)
+  end
+rescue LoadError
+end

data/SIGNALS

@@ -0,0 +1,114 @@
+== Signal handling
+
+In general, signals need only be sent to the master process.  However,
+the signals Unicorn uses internally to communicate with the worker
+processes are documented here as well.  With the exception of TTIN/TTOU,
+signal handling matches the behavior of {nginx}[http://nginx.net/] so it
+should be possible to easily share process management scripts between
+Unicorn and nginx.
+
+=== Master Process
+
+* HUP - reloads config file and gracefully restart all workers.
+  If the "preload_app" directive is false (the default), then workers
+  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.  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
+
+* QUIT - graceful shutdown, waits for workers to finish their
+  current request before finishing.
+
+* USR1 - reopen all logs owned by the master and all workers
+  See Unicorn::Util.reopen_logs for what is considered a log.
+
+* USR2 - reexecute the running binary.  A separate QUIT
+  should be sent to the original process once the child is verified to
+  be up and running.
+
+* WINCH - gracefully stops workers but keep the master running.
+  This will only work for daemonized processes.
+
+* TTIN - increment the number of worker processes by one
+
+* TTOU - decrement the number of worker processes by one
+
+=== Worker Processes
+
+Sending signals directly to the worker processes should not normally be
+needed.  If the master process is running, any exited worker will be
+automatically respawned.
+
+* INT/TERM - Quick shutdown, immediately exit.
+  Unless WINCH has been sent to the master (or the master is killed),
+  the master process will respawn a worker to replace this one.
+
+* QUIT - Gracefully exit after finishing the current request.
+  Unless WINCH has been sent to the master (or the master is killed),
+  the master process will respawn a worker to replace this one.
+
+* USR1 - Reopen all logs owned by the worker process.
+  See Unicorn::Util.reopen_logs for what is considered a log.
+  Log files are not reopened until it is done processing
+  the current request, so multiple log lines for one request
+  (as done by Rails) will not be split across multiple logs.
+
+  It is NOT recommended to send the USR1 signal directly to workers via
+  "killall -USR1 unicorn" if you are using user/group-switching support
+  in your workers.  You will encounter incorrect file permissions and
+  workers will need to be respawned.  Sending USR1 to the master process
+  first will ensure logs have the correct permissions before the master
+  forwards the USR1 signal to workers.
+
+=== Procedure to replace a running unicorn executable
+
+You may replace a running instance of unicorn with a new one without
+losing any incoming connections.  Doing so will reload all of your
+application code, Unicorn config, Ruby executable, and all libraries.
+The only things that will not change (due to OS limitations) are:
+
+1. The path to the unicorn executable script.  If you want to change to
+   a different installation of Ruby, you can modify the shebang
+   line to point to your alternative interpreter.
+
+The procedure is exactly like that of nginx:
+
+1. Send USR2 to the master process
+
+2. Check your process manager or pid files to see if a new master spawned
+   successfully.  If you're using a pid file, the old process will have
+   ".oldbin" appended to its path.  You should have two master instances
+   of unicorn running now, both of which will have workers servicing
+   requests.  Your process tree should look something like this:
+
+     unicorn master (old)
+     \_ unicorn worker[0]
+     \_ unicorn worker[1]
+     \_ unicorn worker[2]
+     \_ unicorn worker[3]
+     \_ unicorn master
+        \_ unicorn worker[0]
+        \_ unicorn worker[1]
+        \_ unicorn worker[2]
+        \_ unicorn worker[3]
+
+3. You can now send WINCH to the old master process so only the new workers
+   serve requests.  If your unicorn process is bound to an interactive
+   terminal, you can skip this step.  Step 5 will be more difficult but
+   you can also skip it if your process is not daemonized.
+
+4. You should now ensure that everything is running correctly with the
+   new workers as the old workers die off.
+
+5. If everything seems ok, then send QUIT to the old master.  You're done!
+
+   If something is broken, then send HUP to the old master to reload
+   the config and restart its workers.  Then send QUIT to the new master
+   process.

data/Sandbox

@@ -0,0 +1,96 @@
+= Tips for using \Unicorn with Sandbox installation tools
+
+Since unicorn includes executables and is usually used to start a Ruby
+process, there are certain caveats to using it with tools that sandbox
+RubyGems installations such as
+{Bundler}[http://gembundler.com/] or
+{Isolate}[http://github.com/jbarnette/isolate].
+
+== General deployment
+
+If you're sandboxing your unicorn installation and using Capistrano (or
+similar), it's required that you sandbox your RubyGems in a per-application
+shared directory that can be used between different revisions.
+
+unicorn will stash its original command-line at startup for the USR2
+upgrades, and cleaning up old revisions will cause revision-specific
+installations of unicorn to go missing and upgrades to fail.   If you
+find yourself in this situation and can't afford downtime, you can
+override the existing unicorn executable path in the config file like
+this:
+
+        Unicorn::HttpServer::START_CTX[0] = "/some/path/to/bin/unicorn"
+
+Then use HUP to reload, and then continue with the USR2+QUIT upgrade
+sequence.
+
+Environment variable pollution when exec-ing a new process (with USR2)
+is the primary issue with sandboxing tools such as Bundler and Isolate.
+
+== Bundler
+
+=== Running
+
+If you're bundling unicorn, use "bundle exec unicorn" (or "bundle exec
+unicorn_rails") to start unicorn with the correct environment variables
+
+ref: http://mid.gmane.org/9ECF07C4-5216-47BE-961D-AFC0F0C82060@internetfamo.us
+
+Otherwise (if you choose to not sandbox your unicorn installation), we
+expect the tips for Isolate (below) apply, too.
+
+=== RUBYOPT pollution from SIGUSR2 upgrades
+
+This is no longer be an issue as of bundler 0.9.17
+
+ref: http://mid.gmane.org/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com
+
+=== BUNDLE_GEMFILE for Capistrano users
+
+You may need to set or reset the BUNDLE_GEMFILE environment variable in
+the before_exec hook:
+
+        before_exec do |server|
+          ENV["BUNDLE_GEMFILE"] = "/path/to/app/current/Gemfile"
+        end
+
+=== Other ENV pollution issues
+
+If you're using an older Bundler version (0.9.x), you may need to set or
+reset GEM_HOME, GEM_PATH and PATH environment variables in the
+before_exec hook as illustrated by http://gist.github.com/534668
+
+== Isolate
+
+=== Running
+
+Installing "unicorn" as a system-wide Rubygem and using the
+isolate gem may cause issues if you're using any of the bundled
+application-level libraries in unicorn/app/* (for compatibility
+with CGI-based applications, Rails <= 2.2.2, or ExecCgi).
+For now workarounds include doing one of the following:
+
+1. Isolating unicorn, setting GEM_HOME to your Isolate path,
+   and running the isolated version of unicorn.  You *must* set
+   GEM_HOME before running your isolated unicorn install in this way.
+
+2.  Installing the same version of unicorn as a system-wide Rubygem
+    *and* isolating unicorn as well.
+
+3. Explicitly setting RUBYLIB or $LOAD_PATH to include any gem path
+   where the unicorn gem is installed
+   (e.g. /usr/lib/ruby/gems/1.9.1/gems/unicorn-VERSION/lib)
+
+=== RUBYOPT pollution from SIGUSR2 upgrades
+
+If you are using Isolate, using Isolate 2.x is strongly recommended as
+environment modifications are idempotent.
+
+If you are stuck with 1.x versions of Isolate, it is recommended that
+you disable it with the <tt>before_exec</tt> hook prevent the PATH and
+RUBYOPT environment variable modifications from propagating between
+upgrades in your Unicorn config file:
+
+        before_exec do |server|
+          Isolate.disable
+        end

data/TODO

@@ -0,0 +1,5 @@
+* Documentation improvements
+
+* improve test suite
+
+* Rack 2.x support (when Rack 2.x exists)

data/TUNING

@@ -0,0 +1,98 @@
+= Tuning \Unicorn
+
+\Unicorn performance is generally as good as a (mostly) Ruby web server
+can provide.  Most often the performance bottleneck is in the web
+application running on Unicorn rather than Unicorn itself.
+
+== \Unicorn Configuration
+
+See Unicorn::Configurator for details on the config file format.
++worker_processes+ is the most-commonly needed tuning parameter.
+
+=== Unicorn::Configurator#worker_processes
+
+* worker_processes should be scaled to the number of processes your
+  backend system(s) can support.  DO NOT scale it to the number of
+  external network clients your application expects to be serving.
+  \Unicorn is NOT for serving slow clients, that is the job of nginx.
+
+* worker_processes should be *at* *least* the number of CPU cores on
+  a dedicated server.  If your application has occasionally slow
+  responses that are /not/ CPU-intensive, you may increase this to
+  workaround those inefficiencies.
+
+* worker_processes may be increased for Unicorn::OobGC users to provide
+  more consistent response times.
+
+* Never, ever, increase worker_processes to the point where the system
+  runs out of physical memory and hits swap.  Production servers should
+  never see heavy swap activity.
+
+=== Unicorn::Configurator#listen Options
+
+* Setting a very low value for the :backlog parameter in "listen"
+  directives can allow failover to happen more quickly if your
+  cluster is configured for it.
+
+* If you're doing extremely simple benchmarks and getting connection
+  errors under high request rates, increasing your :backlog parameter
+  above the already-generous default of 1024 can help avoid connection
+  errors.  Keep in mind this is not recommended for real traffic if
+  you have another machine to failover to (see above).
+
+* :rcvbuf and :sndbuf parameters generally do not need to be set for TCP
+  listeners under Linux 2.6 because auto-tuning is enabled.  UNIX domain
+  sockets do not have auto-tuning buffer sizes; so increasing those will
+  allow syscalls and task switches to be saved for larger requests
+  and responses.  If your app only generates small responses or expects
+  small requests, you may shrink the buffer sizes to save memory, too.
+
+* Having socket buffers too large can also be detrimental or have
+  little effect.  Huge buffers can put more pressure on the allocator
+  and may also thrash CPU caches, cancelling out performance gains
+  one would normally expect.
+
+* UNIX domain sockets are slightly faster than TCP sockets, but only
+  work if nginx is on the same machine.
+
+== Other \Unicorn settings
+
+* Setting "preload_app true" can allow copy-on-write-friendly GC to
+  be used to save memory.  It will probably not work out of the box with
+  applications that open sockets or perform random I/O on files.
+  Databases like TokyoCabinet use concurrency-safe pread()/pwrite()
+  functions for safe sharing of database file descriptors across
+  processes.
+
+* On POSIX-compliant filesystems, it is safe for multiple threads or
+  processes to append to one log file as long as all the processes are
+  have them unbuffered (File#sync = true) or they are
+  record(line)-buffered in userspace before any writes.
+
+== Kernel Parameters (Linux sysctl)
+
+WARNING: Do not change system parameters unless you know what you're doing!
+
+* net.core.rmem_max and net.core.wmem_max can increase the allowed
+  size of :rcvbuf and :sndbuf respectively. This is mostly only useful
+  for UNIX domain sockets which do not have auto-tuning buffer sizes.
+
+* For load testing/benchmarking with UNIX domain sockets, you should
+  consider increasing net.core.somaxconn or else nginx will start
+  failing to connect under heavy load.  You may also consider setting
+  a higher :backlog to listen on as noted earlier.
+
+* If you're running out of local ports, consider lowering
+  net.ipv4.tcp_fin_timeout to 20-30 (default: 60 seconds).  Also
+  consider widening the usable port range by changing
+  net.ipv4.ip_local_port_range.
+
+* Setting net.ipv4.tcp_timestamps=1 will also allow setting
+  net.ipv4.tcp_tw_reuse=1 and net.ipv4.tcp_tw_recycle=1, which along
+  with the above settings can slow down port exhaustion.  Not all
+  networks are compatible with these settings, check with your friendly
+  network administrator before changing these.
+
+* Increasing the MTU size can reduce framing overhead for larger
+  transfers.  One often-overlooked detail is that the loopback
+  device (usually "lo") can have its MTU increased, too.

data/bin/unicorn

@@ -0,0 +1,121 @@
+#!/this/will/be/overwritten/or/wrapped/anyways/do/not/worry/ruby
+# -*- encoding: binary -*-
+require 'unicorn/launcher'
+require 'optparse'
+
+ENV["RACK_ENV"] ||= "development"
+rackup_opts = Unicorn::Configurator::RACKUP
+options = rackup_opts[:options]
+
+op = OptionParser.new("", 24, '  ') do |opts|
+  cmd = File.basename($0)
+  opts.banner = "Usage: #{cmd} " \
+                "[ruby options] [#{cmd} options] [rackup config file]"
+  opts.separator "Ruby options:"
+
+  lineno = 1
+  opts.on("-e", "--eval LINE", "evaluate a LINE of code") do |line|
+    eval line, TOPLEVEL_BINDING, "-e", lineno
+    lineno += 1
+  end
+
+  opts.on("-d", "--debug", "set debugging flags (set $DEBUG to true)") do
+    $DEBUG = true
+  end
+
+  opts.on("-w", "--warn", "turn warnings on for your script") do
+    $-w = true
+  end
+
+  opts.on("-I", "--include PATH",
+          "specify $LOAD_PATH (may be used more than once)") do |path|
+    $LOAD_PATH.unshift(*path.split(/:/))
+  end
+
+  opts.on("-r", "--require LIBRARY",
+          "require the library, before executing your script") do |library|
+    require library
+  end
+
+  opts.separator "#{cmd} options:"
+
+  # some of these switches exist for rackup command-line compatibility,
+
+  opts.on("-o", "--host HOST",
+          "listen on HOST (default: #{Unicorn::Const::DEFAULT_HOST})") do |h|
+    rackup_opts[:host] = h
+    rackup_opts[:set_listener] = true
+  end
+
+  opts.on("-p", "--port PORT",
+          "use PORT (default: #{Unicorn::Const::DEFAULT_PORT})") do |p|
+    rackup_opts[:port] = p.to_i
+    rackup_opts[:set_listener] = true
+  end
+
+  opts.on("-E", "--env RACK_ENV",
+          "use RACK_ENV for defaults (default: development)") do |e|
+    ENV["RACK_ENV"] = e
+  end
+
+  opts.on("-D", "--daemonize", "run daemonized in the background") do |d|
+    rackup_opts[:daemonize] = !!d
+  end
+
+  opts.on("-P", "--pid FILE", "DEPRECATED") do |f|
+    warn %q{Use of --pid/-P is strongly discouraged}
+    warn %q{Use the 'pid' directive in the Unicorn config file instead}
+    options[:pid] = f
+  end
+
+  opts.on("-s", "--server SERVER",
+          "this flag only exists for compatibility") do |s|
+    warn "-s/--server only exists for compatibility with rackup"
+  end
+
+  # Unicorn-specific stuff
+  opts.on("-l", "--listen {HOST:PORT|PATH}",
+          "listen on HOST:PORT or PATH",
+          "this may be specified multiple times",
+          "(default: #{Unicorn::Const::DEFAULT_LISTEN})") do |address|
+    options[:listeners] << address
+  end
+
+  opts.on("-c", "--config-file FILE", "Unicorn-specific config file") do |f|
+    options[:config_file] = f
+  end
+
+  # I'm avoiding Unicorn-specific config options on the command-line.
+  # IMNSHO, config options on the command-line are redundant given
+  # config files and make things unnecessarily complicated with multiple
+  # places to look for a config option.
+
+  opts.separator "Common options:"
+
+  opts.on_tail("-h", "--help", "Show this message") do
+    puts opts.to_s.gsub(/^.*DEPRECATED.*$/s, '')
+    exit
+  end
+
+  opts.on_tail("-v", "--version", "Show version") do
+    puts "#{cmd} v#{Unicorn::Const::UNICORN_VERSION}"
+    exit
+  end
+
+  opts.parse! ARGV
+end
+
+app = Unicorn.builder(ARGV[0] || 'config.ru', op)
+op = nil
+
+if $DEBUG
+  require 'pp'
+  pp({
+    :unicorn_options => options,
+    :app => app,
+    :daemonize => rackup_opts[:daemonize],
+  })
+end
+
+Unicorn::Launcher.daemonize!(options) if rackup_opts[:daemonize]
+Unicorn::HttpServer.new(app, options).start.join