Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Sep 13, 2011
  1. add preliminary SSL support

    Eric Wong authored
    This will also be the foundation of SSL support in Rainbows!
    and Zbatery.  Some users may also want to use this in
    Unicorn on LANs to meet certain security/auditing requirements.
    Of course, Nightmare should also be able to use it.
Commits on Sep 10, 2011
  1. nightmare: add Expect: 100-continue handling

    Eric Wong authored
    We'll blindly tell the client to continue the same way nginx
    does.  This is a corner-case, and folks wanting better control
    of 100-continue in their Rack application should use Rainbows!
    with one of the synchronous concurrency models.
Commits on Sep 9, 2011
  1. quiet down nightmare tests

    Eric Wong authored
    Some debugging messages were left over
Commits on Sep 4, 2011
  1. nightmare: deal with dying upstreams (before response)

    Eric Wong authored
    Upstream servers may die unexpectedly due to apps lacking
    proper timeout mechanisms.  We'll try to return a 502 error
    in that case.
    There isn't much we can do if they die in the middle of writing
    a response, but the chance of that is smaller than dying before
    any response is written.  Parsing the entire response body
    would be too much for a rare case (and keepalive_timeout will
    expire clients, anyways).
Commits on Sep 3, 2011
  1. Nightmare! - an nginx alternative for unicorn

    Eric Wong authored
    This is a slow client buffering layer which may be used instead
    of nginx to protect Unicorn from slow clients.
    Nightmare! will _never_ beat nginx in raw throughput nor
    performance.  It /may/ be easier to setup than nginx and a
    suitable alternative to Rainbows! for users who do not wish to
    maintain a thread-safe/async-safe Rack application.
    Code changes to the existing Unicorn codebase are minimal and
    unlikely to impact existing users.  Nightmare! will never be
    enabled by default.
    Nightmare! supports streaming responses (new in Rails 3.1, but
    ancient to Rack) with "lazy buffering" of upstream responses.
    It'll stream as much of the response as possible immediately and
    then buffer any data that can't.
    Userspace memory buffering is kept to a minimum; if it can't fit
    into generously-sized skbs (at least on modern Linux), it'll
    be buffered to the _filesystem_ (which may be tmpfs or a real FS
    with dirty ratios cranked up).
    HTTPS support is planned/wired.  Somebody with SSL/crypto
    knowledge needs to review
    {kgio-monkey}[] before it can be
    trusted.  V nz n zbaxrl!  Qb abg gehfg zl pbqr!
    Since Nightmare! already uses sendfile to serve buffers, a
    "try_files" directive will be added to bypass Rack for simple
    static file serving.  It will not serve directory indices nor
    gzip, Rack already supports those.
    Nightmare! internals are still in flux, and likely to remain so.
    Like Unicorn internals, do not consider Nightmare itself a
    stable development API unless explicitly told otherwise.
    ****** Use Rack for application logic ******
    Nightmare! should work on Ruby 1.8.x and 1.9.x.
    Configuration directives are not implemented, yet.   Eventually
    it will support operation in standalone mode (so Nightmare! can
    talk to Unicorn on different machines).
    Extra RubyGems required (in addition to what Unicorn requires):
    * kcar - client-side HTTP parser based on the Unicorn one
    * sendfile - for sendfile() support
    * kgio-monkey - (upcoming, optional) for HTTPS support
  2. http_server: a few more things eligible for GC in worker

    Eric Wong authored
    There is no need to keep extra hashes or Proc objects around in
    the heap.
  3. infrastructure for supporting non-Rack worker processes

    Eric Wong authored
    Since we already have a good process management
    infrastructure in place, we can reuse it to manage
    other workers.
Commits on Aug 29, 2011
  1. add GPLv3 option to the license

    Eric Wong authored
    Existing license terms (Ruby-specific) and GPLv2 remain
    in place, but GPLv3 is preferred as it helps with
    distribution of AGPLv3 code and is explicitly compatible
    with Apache License (v2.0).
    Many more reasons are documented by the FSF:
Commits on Aug 25, 2011
  1. unicorn 4.1.1 - fix last-resort timeout accuracy

    Eric Wong authored
    The last-resort timeout mechanism was inaccurate and often
    delayed in activation since the 2.0.0 release.  It is now fixed
    and remains power-efficient in idle situations, especially with
    the wakeup reduction in MRI 1.9.3+.
    There is also a new document on application timeouts
    intended to discourage the reliance on this last-resort
    mechanism.  It is visible on the web at:
  2. doc: add Application Timeouts document

    Eric Wong authored
    Hopefully this leads to fewer worker processes being killed.
Commits on Aug 24, 2011
  1. test_helper: remove needless LOAD_PATH mangling

    Eric Wong authored
    We do it in the Ruby invocation or RUBYLIB.
  2. fix sleep/timeout activation accuracy

    Eric Wong authored
    I've noticed in stderr logs from some folks that (last resort)
    timeouts from the master process are taking too long to activate
    due to the workarounds for suspend/hibernation.
Commits on Aug 22, 2011
  1. .document: re-add OobGC documentation

    Eric Wong authored
Commits on Aug 20, 2011
  1. unicorn 4.1.0 - small updates and fixes

    Eric Wong authored
    * Rack::Chunked and Rack::ContentLength middlewares are loaded
      by default for RACK_ENV=(development|deployment) users to match
      Rack::Server behavior.  As before, use RACK_ENV=none if you want
      fine-grained control of your middleware.  This should also
      help users of Rainbows! and Zbatery.
    * CTL characters are now rejected from HTTP header values
    * Exception messages are now filtered for [:cntrl:] characters
      since application/middleware authors may forget to do so
    * Workers will now terminate properly if a SIGQUIT/SIGTERM/SIGINT
      is received while during worker process initialization.
    * close-on-exec is explicitly disabled to future-proof against
      Ruby 2.0 changes [ruby-core:38140]
  2. rdoc cleanups

    Eric Wong authored
Commits on Aug 19, 2011
  1. close race if an exit signal hits the worker before trap

    Eric Wong authored
    The signal handler from the master is still active and will
    push the pending signal to SIG_QUEUE if a worker receives
    a signal immediately after forking.
  2. gemspec: bump wrongdoc dependency for dev

    Eric Wong authored
    Hopefully it points people towards the mailing list
  3. tests: bump test deps to the latest versions

    Eric Wong authored
    Nothing appears broken :)
  4. Rack::Chunked and ContentLength middlewares by default

    Eric Wong authored
    This is needed to match the behavior of Rack::Server for
    RACK_ENV=(deployment|development), actually.  This won't
    affect users of other RACK_ENV values.
    This change has minor performance consequences, so users
    negatively affected should set RACK_ENV to "none" instead for
    full control of their middleware stack.
    This mainly affects Rainbows!/Zbatery users since they have
    persistent connections and /need/ Content-Length or
    Transfer-Encoding:chunked headers.
  5. filter exception messages with control characters

    Eric Wong authored
    We do not want to affect terminals of users who view our log
Commits on Aug 12, 2011
  1. http_server: small simplification for redirects

    Eric Wong authored
    We only need the fileno in the key which we use
    to generate the UNICORN_FD env.  Otherwise the IO
    object is accepted and understood by Ruby.
Commits on Aug 11, 2011
  1. future-proof against close-on-exec by default

    Eric Wong authored
    Setting the close-on-exec flag by default and closing
    non-standard descriptors is proposed for Ruby 1.9.4/2.0.0.
    Since Unicorn is one of the few apps to rely on FD inheritance
    across exec(), we need to workaround this by redirecting each
    listener FD to itself for Kernel#exec.
    Ruby supports a hash as the final argument to Kernel#exec since
    at least 1.9.1 (nobody cares for 1.9.0 anymore). This allows
    users to backport close-on-exec by default patches to older
    1.9.x installs without breaking anything.
  2. test_socket_helper: Socket#bind may fail with EINVAL if IPv6 is missing

    Eric Wong authored
    I don't build IPv6 into all my kernels; maybe other testers do
    not, either.
Commits on Aug 3, 2011
  1. KNOWN_ISSUES: add link to FreeBSD jail workaround notes

    Eric Wong authored
    Thanks to Tatsuya Ono on the unicorn mailing list.
Commits on Aug 2, 2011
  1. trap death signals in the worker sooner

    Eric Wong authored
    This helps close a race condition preventing shutdown if
    loading the application (preload_app=false) takes a long
    time and the user decides to kil workers instead.
Commits on Jul 20, 2011
  1. http_server: explicitly disable close-on-exec for listeners

    Eric Wong authored
    Future versions of Ruby may change this from the default *nix
    behavior, so we need to explicitly allow FD passing via exec().
Commits on Jul 13, 2011
  1. http: reject non-LWS CTL chars (0..31 + 127) in field values

    Eric Wong authored
    RFC 2616 doesn't appear to allow most CTL bytes even though
    Mongrel always did.  Rack::Lint disallows 0..31, too, though we
    allow "\t" (HT, 09) since it's LWS and allowed by RFC 2616.
Commits on Jul 1, 2011
  1. socket_helper: fix undefined variable for logging

    Eric Wong authored
    I corrupted a Ruby build and SOL_TCP didn't get defined :x
Commits on Jun 29, 2011
  1. unicorn 4.0.1 - regression bugfixes

    Eric Wong authored
    This release fixes things for users of per-worker "listen"
    directives in the after_fork hook.  Thanks to
    for reporting the bug.
    The "timeout" configurator directive is now truncated to
    0x7ffffffe seconds to prevent overflow when calling
  2. configurator: limit timeout to 32-bit INT_MAX-1

    Eric Wong authored
    Nobody will miss one second if they specify an "infinite"
    timeout of ~68 years.  This prevents duplicating this logic
    in Rainbows!
  3. fix per-worker listen directive in after_fork hook

    Eric Wong authored
    The testcase for this was broken, too, so we didn't notice
    this :<
    Reported-by: on the Rainbows! mailing list,
Commits on Jun 27, 2011
  1. configurator: truncate timeouts to 32-bit LONG_MAX

    Eric Wong authored in Ruby can't wait longer than this.  This
    means Unicorn can't support applications that take
    longer than 68 years to respond :(
  2. unicorn 4.0.0 - for mythical hardware!

    Eric Wong authored
    A single Unicorn instance may manage more than 1024 workers
    without needing privileges to modify resource limits.  As a
    result of this, the "raindrops"[1] gem/library is now a required
    TCP socket defaults now favor low latency to mimic UNIX domain
    socket behavior (tcp_nodelay: true, tcp_nopush: false).  This
    hurts throughput, users who want to favor throughput should
    specify "tcp_nodelay: false, tcp_nopush: true" in the listen
    Error logging is more consistent and all lines should be
    formatted correctly in backtraces.  This may break the
    behavior of some log parsers.
    The call stack is smaller and thus easier to examine backtraces
    when debugging Rack applications.
    There are some internal API changes and cleanups, but none that
    affect applications designed for Rack.  See "git log v3.7.0.."
    for details.
    For users who cannot install kgio[2] or raindrops, Unicorn 1.1.x
    remains supported indefinitely.  Unicorn 3.x will remain
    supported if there is demand.  We expect raindrops to introduce
    fewer portability problems than kgio did, however.
  3. slightly faster worker process spawning

    Eric Wong authored
    It's still O(n) since we don't maintain a reverse mapping of
    spawned processes, but at least we avoid the extra overhead of
    creating an array every time.
Commits on Jun 25, 2011
  1. reenable heartbeat checking for idle workers

    Eric Wong authored
    Some applications/libraries may launch background threads which
    can lock up the process.  So we can't disable heartbeat checking
    just because the main thread is sleeping.  This also has the
    side effect of reducing master process wakeups when all workers
    are idle.
Something went wrong with that request. Please try again.