unicorn-fork 6.1.1

data/DESIGN

@@ -0,0 +1,99 @@
+== Design
+
+Unicorn was designed to support poorly-written codebases back in 2008.
+Its unfortunate popularity has only proliferated the existence of
+poorly-written code ever since...
+
+* Simplicity: Unicorn is a traditional UNIX prefork web server.
+  No threads are used at all, this makes applications easier to debug
+  and fix.  When your application goes awry, a BOFH can just
+  "kill -9" the runaway worker process without worrying about tearing
+  all clients down, just one.  Only UNIX-like systems supporting
+  fork() and file descriptor inheritance are supported.
+
+* The Ragel+C HTTP parser is taken from Mongrel.
+
+* All HTTP parsing and I/O is done much like Mongrel:
+    1. read/parse HTTP request headers in full
+    2. call Rack application
+    3. write HTTP response back to the client
+
+* Like Mongrel, neither keepalive nor pipelining are supported.
+  These aren't needed since Unicorn is only designed to serve
+  fast, low-latency clients directly.  Do one thing, do it well;
+  let nginx handle slow clients.
+
+* Configuration is purely in Ruby and eval().  Ruby is less
+  ambiguous than YAML and lets lambdas for
+  before_fork/after_fork/before_exec hooks be defined inline.  An
+  optional, separate config_file may be used to modify supported
+  configuration changes (and also gives you plenty of rope if you RTFS
+  :>)
+
+* One master process spawns and reaps worker processes.  The
+  Rack application itself is called only within the worker process (but
+  can be loaded within the master).  A copy-on-write friendly garbage
+  collector like the one found in mainline Ruby 2.0.0 and later
+  can be used to minimize memory usage along with the "preload_app true"
+  directive (see Unicorn::Configurator).
+
+* The number of worker processes should be scaled to the number of
+  CPUs, memory or even spindles you have.  If you have an existing
+  Mongrel cluster on a single-threaded app, using the same amount of
+  processes should work.  Let a full-HTTP-request-buffering reverse
+  proxy like nginx manage concurrency to thousands of slow clients for
+  you.  Unicorn scaling should only be concerned about limits of your
+  backend system(s).
+
+* Load balancing between worker processes is done by the OS kernel.
+  All workers share a common set of listener sockets and does
+  non-blocking accept() on them.  The kernel will decide which worker
+  process to give a socket to and workers will sleep if there is
+  nothing to accept().
+
+* Since non-blocking accept() is used, there can be a thundering
+  herd when an occasional client connects when application
+  *is not busy*.  The thundering herd problem should not affect
+  applications that are running all the time since worker processes
+  will only select()/accept() outside of the application dispatch.
+
+* Additionally, thundering herds are much smaller than with
+  configurations using existing prefork servers.  Process counts should
+  only be scaled to backend resources, _never_ to the number of expected
+  clients like is typical with blocking prefork servers.  So while we've
+  seen instances of popular prefork servers configured to run many
+  hundreds of worker processes, Unicorn deployments are typically only
+  2-4 processes per-core.
+
+* On-demand scaling of worker processes never happens automatically.
+  Again, Unicorn is concerned about scaling to backend limits and should
+  never configured in a fashion where it could be waiting on slow
+  clients.  For extremely rare circumstances, we provide TTIN and TTOU
+  signal handlers to increment/decrement your process counts without
+  reloading.  Think of it as driving a car with manual transmission:
+  you have a lot more control if you know what you're doing.
+
+* Blocking I/O is used for clients.  This allows a simpler code path
+  to be followed within the Ruby interpreter and fewer syscalls.
+  Applications that use threads continue to work if Unicorn
+  is only serving LAN or localhost clients.
+
+* SIGKILL is used to terminate the timed-out workers from misbehaving apps
+  as reliably as possible on a UNIX system.  The default timeout is a
+  generous 60 seconds (same default as in Mongrel).
+
+* The poor performance of select() on large FD sets is avoided
+  as few file descriptors are used in each worker.
+  There should be no gain from moving to highly scalable but
+  unportable event notification solutions for watching few
+  file descriptors.
+
+* If the master process dies unexpectedly for any reason,
+  workers will notice within :timeout/2 seconds and follow
+  the master to its death.
+
+* There is never any explicit real-time dependency or communication
+  between the worker processes nor to the master process.
+  Synchronization is handled entirely by the OS kernel and shared
+  resources are never accessed by the worker when it is servicing
+  a client.

data/Documentation/.gitignore

@@ -0,0 +1,3 @@
+*.gz
+*.html
+*.txt

data/Documentation/unicorn.1

@@ -0,0 +1,222 @@
+.TH "UNICORN" "1" "September 15, 2009" "Unicorn User Manual" ""
+.hy
+.SH NAME
+.PP
+unicorn \- a rackup\-like command to launch the Unicorn HTTP server
+.SH SYNOPSIS
+.PP
+unicorn [\-c CONFIG_FILE] [\-E RACK_ENV] [\-D] [RACKUP_FILE]
+.SH DESCRIPTION
+.PP
+A rackup(1)\-like command to launch Rack applications using Unicorn.
+It is expected to be started in your application root (APP_ROOT),
+but the "working_directory" directive may be used in the CONFIG_FILE.
+.PP
+While unicorn takes a myriad of command\-line options for
+compatibility with ruby(1) and rackup(1), it is recommended to stick
+to the few command\-line options specified in the SYNOPSIS and use
+the CONFIG_FILE as much as possible.
+.SH RACKUP FILE
+.PP
+This defaults to "config.ru" in APP_ROOT.  It should be the same
+file used by rackup(1) and other Rack launchers, it uses the
+\f[I]Rack::Builder\f[] DSL.
+.PP
+Embedded command\-line options are mostly parsed for compatibility
+with rackup(1) but strongly discouraged.
+.SH UNICORN OPTIONS
+.TP
+.B \-c, \-\-config\-file CONFIG_FILE
+Path to the Unicorn\-specific config file.  The config file is
+implemented as a Ruby DSL, so Ruby code may executed.
+See the RDoc/ri for the \f[I]Unicorn::Configurator\f[] class for the full
+list of directives available from the DSL.
+Using an absolute path for for CONFIG_FILE is recommended as it
+makes multiple instances of Unicorn easily distinguishable when
+viewing ps(1) output.
+.RS
+.RE
+.TP
+.B \-D, \-\-daemonize
+Run daemonized in the background.  The process is detached from
+the controlling terminal and stdin is redirected to "/dev/null".
+Unlike many common UNIX daemons, we do not chdir to "/"
+upon daemonization to allow more control over the startup/upgrade
+process.
+Unless specified in the CONFIG_FILE, stderr and stdout will
+also be redirected to "/dev/null".
+.RS
+.RE
+.TP
+.B \-E, \-\-env RACK_ENV
+Run under the given RACK_ENV.  See the RACK ENVIRONMENT section
+for more details.
+.RS
+.RE
+.TP
+.B \-l, \-\-listen ADDRESS
+Listens on a given ADDRESS.  ADDRESS may be in the form of
+HOST:PORT or PATH, HOST:PORT is taken to mean a TCP socket
+and PATH is meant to be a path to a UNIX domain socket.
+Defaults to "0.0.0.0:8080" (all addresses on TCP port 8080)
+For production deployments, specifying the "listen" directive in
+CONFIG_FILE is recommended as it allows fine\-tuning of socket
+options.
+.RS
+.RE
+.TP
+.B \-N, \-\-no\-default\-middleware
+Disables loading middleware implied by RACK_ENV.  This bypasses the
+configuration documented in the RACK ENVIRONMENT section, but still
+allows RACK_ENV to be used for application/framework\-specific purposes.
+.RS
+.RE
+.SH RACKUP COMPATIBILITY OPTIONS
+.TP
+.B \-o, \-\-host HOST
+Listen on a TCP socket belonging to HOST, default is
+"0.0.0.0" (all addresses).
+If specified multiple times on the command\-line, only the
+last\-specified value takes effect.
+This option only exists for compatibility with the rackup(1) command,
+use of "\-l"/"\-\-listen" switch is recommended instead.
+.RS
+.RE
+.TP
+.B \-p, \-\-port PORT
+Listen on the specified TCP PORT, default is 8080.
+If specified multiple times on the command\-line, only the last\-specified
+value takes effect.
+This option only exists for compatibility with the rackup(1) command,
+use of "\-l"/"\-\-listen" switch is recommended instead.
+.RS
+.RE
+.TP
+.B \-s, \-\-server SERVER
+No\-op, this exists only for compatibility with rackup(1).
+.RS
+.RE
+.SH RUBY OPTIONS
+.TP
+.B \-e, \-\-eval LINE
+Evaluate a LINE of Ruby code.  This evaluation happens
+immediately as the command\-line is being parsed.
+.RS
+.RE
+.TP
+.B \-d, \-\-debug
+Turn on debug mode, the $DEBUG variable is set to true.
+.RS
+.RE
+.TP
+.B \-w, \-\-warn
+Turn on verbose warnings, the $VERBOSE variable is set to true.
+.RS
+.RE
+.TP
+.B \-I, \-\-include PATH
+specify $LOAD_PATH.  PATH will be prepended to $LOAD_PATH.
+The \[aq]:\[aq] character may be used to delimit multiple directories.
+This directive may be used more than once.  Modifications to
+$LOAD_PATH take place immediately and in the order they were
+specified on the command\-line.
+.RS
+.RE
+.TP
+.B \-r, \-\-require LIBRARY
+require a specified LIBRARY before executing the application.  The
+"require" statement will be executed immediately and in the order
+they were specified on the command\-line.
+.RS
+.RE
+.SH SIGNALS
+.PP
+The following UNIX signals may be sent to the master process:
+.IP \[bu] 2
+HUP \- reload config file, app, and gracefully restart all workers
+.IP \[bu] 2
+INT/TERM \- quick shutdown, kills all workers immediately
+.IP \[bu] 2
+QUIT \- graceful shutdown, waits for workers to finish their
+current request before finishing.
+.IP \[bu] 2
+USR1 \- reopen all logs owned by the master and all workers
+See Unicorn::Util.reopen_logs for what is considered a log.
+.IP \[bu] 2
+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.
+.IP \[bu] 2
+WINCH \- gracefully stops workers but keep the master running.
+This will only work for daemonized processes.
+.IP \[bu] 2
+TTIN \- increment the number of worker processes by one
+.IP \[bu] 2
+TTOU \- decrement the number of worker processes by one
+.PP
+See the SIGNALS (https://yhbt.net/unicorn/SIGNALS.html) document for
+full description of all signals used by Unicorn.
+.SH RACK ENVIRONMENT
+.PP
+Accepted values of RACK_ENV and the middleware they automatically load
+(outside of RACKUP_FILE) are exactly as those in rackup(1):
+.IP \[bu] 2
+development \- loads Rack::CommonLogger, Rack::ShowExceptions, and
+              Rack::Lint middleware
+.IP \[bu] 2
+deployment \- loads Rack::CommonLogger middleware
+.IP \[bu] 2
+none \- loads no middleware at all, relying entirely on RACKUP_FILE
+.PP
+All unrecognized values for RACK_ENV are assumed to be
+"none".  Production deployments are strongly encouraged to use
+"deployment" or "none" for maximum performance.
+.PP
+As of Unicorn 0.94.0, RACK_ENV is exported as a process\-wide environment
+variable as well.  While not current a part of the Rack specification as
+of Rack 1.0.1, this has become a de facto standard in the Rack world.
+.PP
+Note the Rack::ContentLength middleware is also
+loaded by "deployment" and "development", but no other values of
+RACK_ENV.  If needed, they must be individually specified in the
+RACKUP_FILE, some frameworks do not require them.
+.SH ENVIRONMENT VARIABLES
+.PP
+The RACK_ENV variable is set by the aforementioned \-E switch.
+All application or library\-specific environment variables (e.g. TMPDIR)
+may always be set in the Unicorn CONFIG_FILE in addition to the spawning
+shell.  When transparently upgrading Unicorn, all environment variables
+set in the old master process are inherited by the new master process.
+Unicorn only uses (and will overwrite) the UNICORN_FD environment
+variable internally when doing transparent upgrades.
+.PP
+UNICORN_FD is a comma\-delimited list of one or more file descriptors
+used to implement USR2 upgrades.  Init systems may bind listen sockets
+itself and spawn unicorn with UNICORN_FD set to the file descriptor
+numbers of the listen socket(s).
+.PP
+As of unicorn 5.0, LISTEN_PID and LISTEN_FDS are used for socket
+activation as documented in the sd_listen_fds(3) manpage.  Users
+relying on this feature do not need to specify a listen socket in
+the unicorn config file.
+.SH SEE ALSO
+.IP \[bu] 2
+\f[I]Rack::Builder\f[] ri/RDoc
+.IP \[bu] 2
+\f[I]Unicorn::Configurator\f[] ri/RDoc
+.UR https://yhbt.net/unicorn/Unicorn/Configurator.html
+.UE
+.IP \[bu] 2
+unicorn RDoc
+.UR https://yhbt.net/unicorn/
+.UE
+.IP \[bu] 2
+Rack RDoc
+.UR https://www.rubydoc.info/github/rack/rack/
+.UE
+.IP \[bu] 2
+Rackup HowTo
+.UR https://github.com/rack/rack/wiki/(tutorial)-rackup-howto
+.UE
+.SH AUTHORS
+The Unicorn Community <unicorn-public@yhbt.net>.

data/Documentation/unicorn_rails.1

@@ -0,0 +1,207 @@
+.TH "UNICORN_RAILS" "1" "September 17, 2009" "Unicorn User Manual" ""
+.hy
+.SH NAME
+.PP
+unicorn_rails \- unicorn launcher for Rails 1.x and 2.x users
+.SH SYNOPSIS
+.PP
+unicorn_rails [\-c CONFIG_FILE] [\-E RAILS_ENV] [\-D] [RACKUP_FILE]
+.SH DESCRIPTION
+.PP
+A rackup(1)\-like command to launch ancient Rails (2.x and earlier)
+applications using Unicorn.  Rails 3 (and later) support Rack natively,
+so users are encouraged to use unicorn(1) instead of unicorn_rails(1).
+.PP
+It is expected to be started in your Rails application root (RAILS_ROOT),
+but the "working_directory" directive may be used in the CONFIG_FILE.
+.PP
+The outward interface resembles rackup(1), the internals and default
+middleware loading is designed like the \f[C]script/server\f[] command
+distributed with Rails.
+.PP
+While Unicorn takes a myriad of command\-line options for compatibility
+with ruby(1) and rackup(1), it is recommended to stick to the few
+command\-line options specified in the SYNOPSIS and use the CONFIG_FILE
+as much as possible.
+.SH UNICORN OPTIONS
+.TP
+.B \-c, \-\-config\-file CONFIG_FILE
+Path to the Unicorn\-specific config file.  The config file is
+implemented as a Ruby DSL, so Ruby code may executed.
+See the RDoc/ri for the \f[I]Unicorn::Configurator\f[] class for the full
+list of directives available from the DSL.
+Using an absolute path for for CONFIG_FILE is recommended as it
+makes multiple instances of Unicorn easily distinguishable when
+viewing ps(1) output.
+.RS
+.RE
+.TP
+.B \-D, \-\-daemonize
+Run daemonized in the background.  The process is detached from
+the controlling terminal and stdin is redirected to "/dev/null".
+Unlike many common UNIX daemons, we do not chdir to "/" upon
+daemonization to allow more control over the startup/upgrade
+process.
+Unless specified in the CONFIG_FILE, stderr and stdout will
+also be redirected to "/dev/null".
+Daemonization will \f[I]skip\f[] loading of the
+\f[I]Rails::Rack::LogTailer\f[]
+middleware under Rails >= 2.3.x.
+By default, unicorn_rails(1) will create a PID file in
+\f[I]"RAILS_ROOT/tmp/pids/unicorn.pid"\f[].  You may override this
+by specifying the "pid" directive to override this Unicorn config file.
+.RS
+.RE
+.TP
+.B \-E, \-\-env RAILS_ENV
+Run under the given RAILS_ENV.  This sets the RAILS_ENV environment
+variable.  Acceptable values are exactly those you expect in your Rails
+application, typically "development" or "production".
+.RS
+.RE
+.TP
+.B \-l, \-\-listen ADDRESS
+Listens on a given ADDRESS.  ADDRESS may be in the form of
+HOST:PORT or PATH, HOST:PORT is taken to mean a TCP socket
+and PATH is meant to be a path to a UNIX domain socket.
+Defaults to "0.0.0.0:8080" (all addresses on TCP port 8080).
+For production deployments, specifying the "listen" directive in
+CONFIG_FILE is recommended as it allows fine\-tuning of socket
+options.
+.RS
+.RE
+.SH RACKUP COMPATIBILITY OPTIONS
+.TP
+.B \-o, \-\-host HOST
+Listen on a TCP socket belonging to HOST, default is
+"0.0.0.0" (all addresses).
+If specified multiple times on the command\-line, only the
+last\-specified value takes effect.
+This option only exists for compatibility with the rackup(1) command,
+use of "\-l"/"\-\-listen" switch is recommended instead.
+.RS
+.RE
+.TP
+.B \-p, \-\-port PORT
+Listen on the specified TCP PORT, default is 8080.
+If specified multiple times on the command\-line, only the last\-specified
+value takes effect.
+This option only exists for compatibility with the rackup(1) command,
+use of "\-l"/"\-\-listen" switch is recommended instead.
+.RS
+.RE
+.TP
+.B \-\-path PATH
+Mounts the Rails application at the given PATH (instead of "/").
+This is equivalent to setting the RAILS_RELATIVE_URL_ROOT
+environment variable.  This is only supported under Rails 2.3
+or later at the moment.
+.RS
+.RE
+.SH RUBY OPTIONS
+.TP
+.B \-e, \-\-eval LINE
+Evaluate a LINE of Ruby code.  This evaluation happens
+immediately as the command\-line is being parsed.
+.RS
+.RE
+.TP
+.B \-d, \-\-debug
+Turn on debug mode, the $DEBUG variable is set to true.
+For Rails >= 2.3.x, this loads the \f[I]Rails::Rack::Debugger\f[]
+middleware.
+.RS
+.RE
+.TP
+.B \-w, \-\-warn
+Turn on verbose warnings, the $VERBOSE variable is set to true.
+.RS
+.RE
+.TP
+.B \-I, \-\-include PATH
+specify $LOAD_PATH.  PATH will be prepended to $LOAD_PATH.
+The \[aq]:\[aq] character may be used to delimit multiple directories.
+This directive may be used more than once.  Modifications to
+$LOAD_PATH take place immediately and in the order they were
+specified on the command\-line.
+.RS
+.RE
+.TP
+.B \-r, \-\-require LIBRARY
+require a specified LIBRARY before executing the application.  The
+"require" statement will be executed immediately and in the order
+they were specified on the command\-line.
+.RS
+.RE
+.SH RACKUP FILE
+.PP
+This defaults to "config.ru" in RAILS_ROOT.  It should be the same
+file used by rackup(1) and other Rack launchers, it uses the
+\f[I]Rack::Builder\f[] DSL.  Unlike many other Rack applications, RACKUP_FILE
+is completely \f[I]optional\f[] for Rails, but may be used to disable
+some of the default middleware for performance.
+.PP
+Embedded command\-line options are mostly parsed for compatibility
+with rackup(1) but strongly discouraged.
+.SH ENVIRONMENT VARIABLES
+.PP
+The RAILS_ENV variable is set by the aforementioned \-E switch.  The
+RAILS_RELATIVE_URL_ROOT is set by the aforementioned \-\-path switch.
+Either of these variables may also be set in the shell or the Unicorn
+CONFIG_FILE.  All application or library\-specific environment variables
+(e.g. TMPDIR, RAILS_ASSET_ID) may always be set in the Unicorn
+CONFIG_FILE in addition to the spawning shell.  When transparently
+upgrading Unicorn, all environment variables set in the old master
+process are inherited by the new master process.  Unicorn only uses (and
+will overwrite) the UNICORN_FD environment variable internally when
+doing transparent upgrades.
+.SH SIGNALS
+.PP
+The following UNIX signals may be sent to the master process:
+.IP \[bu] 2
+HUP \- reload config file, app, and gracefully restart all workers
+.IP \[bu] 2
+INT/TERM \- quick shutdown, kills all workers immediately
+.IP \[bu] 2
+QUIT \- graceful shutdown, waits for workers to finish their current
+request before finishing.
+.IP \[bu] 2
+USR1 \- reopen all logs owned by the master and all workers
+See Unicorn::Util.reopen_logs for what is considered a log.
+.IP \[bu] 2
+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.
+.IP \[bu] 2
+WINCH \- gracefully stops workers but keep the master running.
+This will only work for daemonized processes.
+.IP \[bu] 2
+TTIN \- increment the number of worker processes by one
+.IP \[bu] 2
+TTOU \- decrement the number of worker processes by one
+.PP
+See the SIGNALS (https://yhbt.net/unicorn/SIGNALS.html) document for
+full description of all signals used by Unicorn.
+.SH SEE ALSO
+.IP \[bu] 2
+unicorn(1)
+.IP \[bu] 2
+\f[I]Rack::Builder\f[] ri/RDoc
+.IP \[bu] 2
+\f[I]Unicorn::Configurator\f[] ri/RDoc
+.UR https://yhbt.net/unicorn/Unicorn/Configurator.html
+.UE
+.IP \[bu] 2
+unicorn RDoc
+.UR https://yhbt.net/unicorn/
+.UE
+.IP \[bu] 2
+Rack RDoc
+.UR https://www.rubydoc.info/github/rack/rack/
+.UE
+.IP \[bu] 2
+Rackup HowTo
+.UR https://github.com/rack/rack/wiki/(tutorial)-rackup-howto
+.UE
+.SH AUTHORS
+The Unicorn Community <unicorn-public@yhbt.net>.

data/FAQ

@@ -0,0 +1,70 @@
+= Frequently Asked Questions about Unicorn
+
+=== Why is nginx getting ECONNRESET as a reverse proxy?
+
+Request body data (commonly from POST and PUT requests) may not be
+drained entirely by the application.  This may happen when request
+bodies are gzipped, as unicorn reads request body data lazily to avoid
+overhead from bad requests.
+
+Ref: https://yhbt.net/unicorn-public/FC91211E-FD32-432C-92FC-0318714C2170@zendesk.com/
+
+=== Why aren't my Rails log files rotated when I use SIGUSR1?
+
+The Rails autoflush_log option must remain disabled with multiprocess
+servers such as unicorn.  Buffering in userspace may cause lines to be
+partially written and lead to corruption in the presence of multiple
+processes.  With reasonable amounts of logging, the performance impact
+of autoflush_log should be negligible on Linux and other modern kernels.
+
+=== Why are my redirects going to "http" URLs when my site uses https?
+
+If your site is entirely behind https, then Rack applications that use
+"rack.url_scheme" can set the following in the Unicorn config file:
+
+  HttpRequest::DEFAULTS["rack.url_scheme"] = "https"
+
+For frameworks that do not use "rack.url_scheme", you can also
+try setting one or both of the following:
+
+  HttpRequest::DEFAULTS["HTTPS"] = "on"
+  HttpRequest::DEFAULTS["HTTP_X_FORWARDED_PROTO"] = "https"
+
+Otherwise, you can configure your proxy (nginx) to send the
+"X-Forwarded-Proto: https" header only for parts of the site that use
+https.  For nginx, you can do it with the following line in appropriate
+"location" blocks of your nginx config file:
+
+  proxy_set_header X-Forwarded-Proto https;
+
+=== Why are log messages from Unicorn are unformatted when using Rails?
+
+Current versions of Rails unfortunately overrides the default Logger
+formatter.
+
+You can undo this behavior with the default logger in your Unicorn
+config file:
+
+  Configurator::DEFAULTS[:logger].formatter = Logger::Formatter.new
+
+Of course you can specify an entirely different logger as well
+with the "logger" directive described by Unicorn::Configurator.
+
+=== Why am I getting "connection refused"/502 errors under high load?
+
+Short answer: your application cannot keep up.
+
+You can increase the size of the :backlog parameter if your kernel
+supports a larger listen() queue, but keep in mind having a large listen
+queue makes failover to a different machine more difficult.
+
+See the TUNING and Unicorn::Configurator documents for more information
+on :backlog-related topics.
+
+=== I've installed Rack 1.1.x, why can't Unicorn load Rails (2.3.5)?
+
+Rails 2.3.5 is not compatible with Rack 1.1.x.  Unicorn is compatible
+with both Rack 1.1.x and Rack 1.0.x, and RubyGems will load the latest
+version of Rack installed on the system.  Uninstalling the Rack 1.1.x
+gem should solve gem loading issues with Rails 2.3.5.  Rails 2.3.6
+and later correctly support Rack 1.1.x.

data/GIT-VERSION-FILE

@@ -0,0 +1 @@
+GIT_VERSION = 6.1.0.68.ge9862.dirty

data/GIT-VERSION-GEN

@@ -0,0 +1,39 @@
+#!/usr/bin/env ruby
+DEF_VER = "v6.1.0"
+CONSTANT = "Unicorn::Const::UNICORN_VERSION"
+RVF = "lib/unicorn/version.rb"
+GVF = "GIT-VERSION-FILE"
+vn = DEF_VER
+
+# First see if there is a version file (included in release tarballs),
+# then try git-describe, then default.
+if File.exist?(".git")
+  describe = `git describe --abbrev=4 HEAD 2>/dev/null`.strip
+  case describe
+  when /\Av[0-9]*/
+    vn = describe
+    system(*%w(git update-index -q --refresh))
+    unless `git diff-index --name-only HEAD --`.chomp.empty?
+      vn << "-dirty"
+    end
+    vn.tr!('-', '.')
+  end
+end
+
+vn = vn.sub!(/\Av/, "")
+
+# generate the Ruby constant
+new_ruby_version = "#{CONSTANT} = '#{vn}'\n"
+cur_ruby_version = File.read(RVF) rescue nil
+if new_ruby_version != cur_ruby_version
+  File.open(RVF, "w") { |fp| fp.write(new_ruby_version) }
+end
+
+# generate the makefile snippet
+new_make_version = "GIT_VERSION = #{vn}\n"
+cur_make_version = File.read(GVF) rescue nil
+if new_make_version != cur_make_version
+  File.open(GVF, "w") { |fp| fp.write(new_make_version) }
+end
+
+puts vn if $0 == __FILE__