unicorn 5.4.1 → 6.1.0

data/Documentation/unicorn.1.txt

@@ -1,187 +0,0 @@
-% UNICORN(1) Unicorn User Manual
-% The Unicorn Community <unicorn-public@bogomips.org>
-% September 15, 2009
-
-# NAME
-
-unicorn - a rackup-like command to launch the Unicorn HTTP server
-
-# SYNOPSIS
-
-unicorn [-c CONFIG_FILE] [-E RACK_ENV] [-D] [RACKUP_FILE]
-
-# DESCRIPTION
-
-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.
-
-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.
-
-# RACKUP FILE
-
-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
-*Rack::Builder* DSL.
-
-Embedded command-line options are mostly parsed for compatibility
-with rackup(1) but strongly discouraged.
-
-# UNICORN OPTIONS
--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 *Unicorn::Configurator* 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.
-
--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".
-
--E, \--env RACK_ENV
-:   Run under the given RACK_ENV.  See the RACK ENVIRONMENT section
-    for more details.
-
--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.
--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.
-
-# RACKUP COMPATIBILITY OPTIONS
--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.
-
--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.
-
--s, \--server SERVER
-:   No-op, this exists only for compatibility with rackup(1).
-
-# RUBY OPTIONS
--e, \--eval LINE
-:   Evaluate a LINE of Ruby code.  This evaluation happens
-    immediately as the command-line is being parsed.
-
--d, \--debug
-:   Turn on debug mode, the $DEBUG variable is set to true.
-
--w, \--warn
-:   Turn on verbose warnings, the $VERBOSE variable is set to true.
-
--I, \--include PATH
-:   specify $LOAD_PATH.  PATH will be prepended to $LOAD_PATH.
-    The \':\' 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.
-
--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.
-
-# SIGNALS
-
-The following UNIX signals may be sent to the master process:
-
-* HUP - reload config file, app, and gracefully restart all workers
-* 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
-
-See the [SIGNALS][4] document for full description of all signals
-used by Unicorn.
-
-#  RACK ENVIRONMENT
-
-Accepted values of RACK_ENV and the middleware they automatically load
-(outside of RACKUP_FILE) are exactly as those in rackup(1):
-
-* development - loads Rack::CommonLogger, Rack::ShowExceptions, and
-                Rack::Lint middleware
-* deployment  - loads Rack::CommonLogger middleware
-* none        - loads no middleware at all, relying
-                entirely on RACKUP_FILE
-
-All unrecognized values for RACK_ENV are assumed to be
-"none".  Production deployments are strongly encouraged to use
-"deployment" or "none" for maximum performance.
-
-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.
-
-Note the Rack::ContentLength and Rack::Chunked middlewares are 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.
-
-# ENVIRONMENT VARIABLES
-
-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.
-
-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).
-
-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.
-
-# SEE ALSO
-
-* *Rack::Builder* ri/RDoc
-* *Unicorn::Configurator* ri/RDoc
-* [Unicorn RDoc][1]
-* [Rack RDoc][2]
-* [Rackup HowTo][3]
-
-[1]: https://bogomips.org/unicorn/
-[2]: http://www.rubydoc.info/github/rack/rack/
-[3]: https://github.com/rack/rack/wiki/tutorial-rackup-howto
-[4]: https://bogomips.org/unicorn/SIGNALS.html

data/Documentation/unicorn_rails.1.txt

@@ -1,175 +0,0 @@
-% UNICORN_RAILS(1) Unicorn User Manual
-% The Unicorn Community <unicorn-public@bogomips.org>
-% September 17, 2009
-
-# NAME
-
-unicorn_rails - unicorn launcher for Rails 1.x and 2.x users
-
-# SYNOPSIS
-
-unicorn_rails [-c CONFIG_FILE] [-E RAILS_ENV] [-D] [RACKUP_FILE]
-
-# DESCRIPTION
-
-A rackup(1)-like command to launch Rails applications using Unicorn.  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.
-
-It is designed to help Rails 1.x and 2.y users transition to Rack, but
-it is NOT needed for Rails 3 applications.  Rails 3 users are encouraged
-to use unicorn(1) instead of unicorn_rails(1).  Users of Rails 1.x/2.y
-may also use unicorn(1) instead of unicorn_rails(1).
-
-The outward interface resembles rackup(1), the internals and default
-middleware loading is designed like the `script/server` command
-distributed with Rails.
-
-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.
-
-# UNICORN OPTIONS
--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 *Unicorn::Configurator* 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.
-
--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 _skip_ loading of the *Rails::Rack::LogTailer*
-    middleware under Rails \>\= 2.3.x.
-    By default, unicorn\_rails(1) will create a PID file in
-    _\"RAILS\_ROOT/tmp/pids/unicorn.pid\"_.  You may override this
-    by specifying the "pid" directive to override this Unicorn config file.
-
--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".
-
--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.
-
-# RACKUP COMPATIBILITY OPTIONS
--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.
-
--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.
-
-\--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.
-
-# RUBY OPTIONS
--e, \--eval LINE
-:   Evaluate a LINE of Ruby code.  This evaluation happens
-    immediately as the command-line is being parsed.
-
--d, \--debug
-:   Turn on debug mode, the $DEBUG variable is set to true.
-    For Rails \>\= 2.3.x, this loads the *Rails::Rack::Debugger*
-    middleware.
-
--w, \--warn
-:   Turn on verbose warnings, the $VERBOSE variable is set to true.
-
--I, \--include PATH
-:   specify $LOAD_PATH.  PATH will be prepended to $LOAD_PATH.
-    The \':\' 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.
-
--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.
-
-# RACKUP FILE
-
-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
-*Rack::Builder* DSL.  Unlike many other Rack applications, RACKUP_FILE
-is completely _optional_ for Rails, but may be used to disable some
-of the default middleware for performance.
-
-Embedded command-line options are mostly parsed for compatibility
-with rackup(1) but strongly discouraged.
-
-# ENVIRONMENT VARIABLES
-
-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.
-
-# SIGNALS
-
-The following UNIX signals may be sent to the master process:
-
-* HUP - reload config file, app, and gracefully restart all workers
-* 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
-
-See the [SIGNALS][4] document for full description of all signals
-used by Unicorn.
-
-# SEE ALSO
-
-* unicorn(1)
-* *Rack::Builder* ri/RDoc
-* *Unicorn::Configurator* ri/RDoc
-* [Unicorn RDoc][1]
-* [Rack RDoc][2]
-* [Rackup HowTo][3]
-
-[1]: https://bogomips.org/unicorn/
-[2]: http://www.rubydoc.info/github/rack/rack/
-[3]: https://github.com/rack/rack/wiki/tutorial-rackup-howto
-[4]: https://bogomips.org/unicorn/SIGNALS.html

data/t/hijack.ru

@@ -1,55 +0,0 @@
-use Rack::Lint
-use Rack::ContentLength
-use Rack::ContentType, "text/plain"
-class DieIfUsed
-  @@n = 0
-  def each
-    abort "body.each called after response hijack\n"
-  end
-
-  def close
-    warn "closed DieIfUsed #{@@n += 1}\n"
-  end
-end
-
-envs = []
-
-run lambda { |env|
-  case env["PATH_INFO"]
-  when "/hijack_req"
-    if env["rack.hijack?"]
-      io = env["rack.hijack"].call
-      envs << env
-      if io.respond_to?(:read_nonblock) &&
-         env["rack.hijack_io"].respond_to?(:read_nonblock)
-
-        # exercise both, since we Rack::Lint may use different objects
-        env["rack.hijack_io"].write("HTTP/1.0 200 OK\r\n\r\n")
-        io.write("request.hijacked")
-        io.close
-        return [ 500, {}, DieIfUsed.new ]
-      end
-    end
-    [ 500, {}, [ "hijack BAD\n" ] ]
-  when "/hijack_res"
-    r = "response.hijacked"
-    [ 200,
-      {
-        "Content-Length" => r.bytesize.to_s,
-        "rack.hijack" => proc do |io|
-          envs << env
-          io.write(r)
-          io.close
-        end
-      },
-      DieIfUsed.new
-    ]
-  when "/normal_env_id"
-    b = "#{env.object_id}\n"
-    h = {
-      'Content-Type' => 'text/plain',
-      'Content-Length' => b.bytesize.to_s,
-    }
-    [ 200, h, [ b ] ]
-  end
-}

data/t/t0200-rack-hijack.sh

@@ -1,51 +0,0 @@
-#!/bin/sh
-. ./test-lib.sh
-t_plan 9 "rack.hijack tests (Rack 1.5+ (Rack::VERSION >= [ 1,2]))"
-
-t_begin "setup and start" && {
-	unicorn_setup
-	unicorn -D -c $unicorn_config hijack.ru
-	unicorn_wait_start
-}
-
-t_begin "normal env reused between requests" && {
-	env_a="$(curl -sSf http://$listen/normal_env_id)"
-	b="$(curl -sSf http://$listen/normal_env_id)"
-	test x"$env_a" = x"$b"
-}
-
-t_begin "check request hijack" && {
-	test "xrequest.hijacked" = x"$(curl -sSfv http://$listen/hijack_req)"
-}
-
-t_begin "env changed after request hijack" && {
-	env_b="$(curl -sSf http://$listen/normal_env_id)"
-	test x"$env_a" != x"$env_b"
-}
-
-t_begin "check response hijack" && {
-	test "xresponse.hijacked" = x"$(curl -sSfv http://$listen/hijack_res)"
-}
-
-t_begin "env changed after response hijack" && {
-	env_c="$(curl -sSf http://$listen/normal_env_id)"
-	test x"$env_b" != x"$env_c"
-}
-
-t_begin "env continues to be reused between requests" && {
-	b="$(curl -sSf http://$listen/normal_env_id)"
-	test x"$env_c" = x"$b"
-}
-
-t_begin "killing succeeds after hijack" && {
-	kill $unicorn_pid
-}
-
-t_begin "check stderr for hijacked body close" && {
-	check_stderr
-	grep 'closed DieIfUsed 1\>' $r_err
-	grep 'closed DieIfUsed 2\>' $r_err
-	! grep 'closed DieIfUsed 3\>' $r_err
-}
-
-t_done