Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Sep 13, 2011

  1. add preliminary SSL support

    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.
    Eric Wong authored

Sep 10, 2011

  1. nightmare: add Expect: 100-continue handling

    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.
    Eric Wong authored

Sep 09, 2011

  1. quiet down nightmare tests

    Some debugging messages were left over
    Eric Wong authored

Sep 04, 2011

  1. nightmare: deal with dying upstreams (before response)

    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).
    Eric Wong authored

Sep 03, 2011

  1. Nightmare! - an nginx alternative for unicorn

    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
    Eric Wong authored
  2. http_server: a few more things eligible for GC in worker

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

    Since we already have a good process management
    infrastructure in place, we can reuse it to manage
    other workers.
    Eric Wong authored

Aug 29, 2011

  1. add GPLv3 option to the license

    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:
    Eric Wong authored

Aug 25, 2011

  1. unicorn 4.1.1 - fix last-resort timeout accuracy

    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:
    Eric Wong authored
  2. doc: add Application Timeouts document

    Hopefully this leads to fewer worker processes being killed.
    Eric Wong authored

Aug 24, 2011

  1. test_helper: remove needless LOAD_PATH mangling

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

    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.
    Eric Wong authored

Aug 22, 2011

  1. .document: re-add OobGC documentation

    Eric Wong authored

Aug 20, 2011

  1. unicorn 4.1.0 - small updates and fixes

    * 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]
    Eric Wong authored
  2. rdoc cleanups

    Eric Wong authored

Aug 19, 2011

  1. close race if an exit signal hits the worker before trap

    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.
    Eric Wong authored
  2. gemspec: bump wrongdoc dependency for dev

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

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

    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.
    Eric Wong authored
  5. filter exception messages with control characters

    We do not want to affect terminals of users who view our log
    Eric Wong authored

Aug 12, 2011

  1. http_server: small simplification for redirects

    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.
    Eric Wong authored

Aug 11, 2011

  1. future-proof against close-on-exec by default

    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.
    Eric Wong authored
  2. test_socket_helper: Socket#bind may fail with EINVAL if IPv6 is missing

    I don't build IPv6 into all my kernels; maybe other testers do
    not, either.
    Eric Wong authored

Aug 03, 2011

  1. KNOWN_ISSUES: add link to FreeBSD jail workaround notes

    Thanks to Tatsuya Ono on the unicorn mailing list.
    Eric Wong authored

Aug 02, 2011

  1. trap death signals in the worker sooner

    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.
    Eric Wong authored

Jul 20, 2011

  1. http_server: explicitly disable close-on-exec for listeners

    Future versions of Ruby may change this from the default *nix
    behavior, so we need to explicitly allow FD passing via exec().
    Eric Wong authored

Jul 13, 2011

  1. http: reject non-LWS CTL chars (0..31 + 127) in field values

    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.
    Eric Wong authored

Jul 01, 2011

  1. socket_helper: fix undefined variable for logging

    I corrupted a Ruby build and SOL_TCP didn't get defined :x
    Eric Wong authored

Jun 29, 2011

  1. unicorn 4.0.1 - regression bugfixes

    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
    Eric Wong authored
  2. configurator: limit timeout to 32-bit INT_MAX-1

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

    The testcase for this was broken, too, so we didn't notice
    this :<
    Reported-by: on the Rainbows! mailing list,
    Eric Wong authored

Jun 27, 2011

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

    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.
    Eric Wong authored
  3. slightly faster worker process spawning

    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.
    Eric Wong authored

Jun 25, 2011

  1. reenable heartbeat checking for idle workers

    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.
    Eric Wong authored
Something went wrong with that request. Please try again.