| Date | Commit message (Collapse) |
|---|
|
The "working_directory" configuration parameter is now handled
before config.ru. That means "unicorn" and "unicorn_rails" no
longer barfs when initially started outside of the configured
"working_directory" where a config.ru is required. A huge
thanks to Pierre Baillet for catching this ugly UI inconsistency
before the big 1.0 release
Thanks to Hongli Lai, out-of-the-box Rails 3 (beta) support
should be improved for deployments lacking a config.ru
There are more new integration tests, cleanups and some
documentation improvements.
|
|
While we're at it, inform people of why they might use
a symlink
|
|
|
|
|
|
Since we added support for the "working_directory" parameter, it
often became unclear where/when certain paths would be bound.
There are some extremely nasty dependencies and ordering issues
when doing this. It's all pretty fragile, but works for now
and we even have a full integration test to keep it working.
I plan on cleaning this up 2.x.x to be less offensive to look
at (Rainbows! and Zbatery are a bit tied to this at the moment).
Thanks to Pierre Baillet for reporting this.
ref: http://mid.gmane.org/AANLkTimKb7JARr_69nfVrJLvMZH3Gvs1o_KwZFLKfuxy@mail.gmail.com
|
|
Rainbows! and Zbatery have long been upgraded to
pass options to us.
|
|
Thanks to Augusto Becciu for finding a bug in the HTTP parser
that caused a TypeError (and 500) when a rare client set the
"Version:" header which conflicts with the HTTP_VERSION header
we parse in the first line of the request[1].
Horizontal tabs are now allowed as leading whitespace in header
values as according to RFC 2616 as pointed out by
Iñaki Baz Castillo[2].
Taking a hint from Rack 1.1, the "logger" configuration
parameter no longer requires a "close" method. This means some
more Logger replacements may be used.
There's a new, optional, Unicorn (and maybe Passenger)-only
middleware, Unicorn::OobGC[2] that runs GC outside of the normal
request/response cycle to help out memory-hungry applications.
Thanks to Luke Melia for being brave enough to test and report
back on my big_app_gc.rb monkey patch[3] which lead up to this.
Rails 3 (beta) support:
Using "unicorn" is still recommended as Rails 3 comes with
a config.ru, but "unicorn_rails" is cleaned up a bit and
*should* work as well as "unicorn" out-of-the-box. Feedback
is much appreciated.
Rubinius updates:
USR2 binary upgrades are broken due to
{TCPServer,UNIXServer}.for_fd[5][6] being broken
(differently).
Repeatedly hitting the server with signals in a tight
loop is unusual and not recommended[7].
There are some workarounds and general code cleanups for other
issues[8], as well but things should generally work unless you
need USR2 upgrades. Feedback and reports would be greatly
appreciated as usual.
MRI support:
All tests (except old Rails) run and pass under 1.9.2-preview3.
1.8.7 and 1.9.1 work well as usual and will continue to be
supported indefinitely.
Lets hope this is the last release before 1.0. Please report
any issues on the mailing list[9] or email us privately[a].
Don't send HTML mail.
[1] - http://mid.gmane.org/AANLkTimuGgcwNAMcVZdViFWdF-UcW_RGyZAue7phUXps@mail.gmail.com
[2] - http://mid.gmane.org/i2xcc1f582e1005070651u294bd83oc73d1e0adf72373a@mail.gmail.com
[3] - http://unicorn.bogomips.org/Unicorn/OobGC.html
[4] - http://unicorn.bogomips.org/examples/big_app_gc.rb
[5] - http://github.com/evanphx/rubinius/issues/354
[6] - http://github.com/evanphx/rubinius/issues/355
[7] - http://github.com/evanphx/rubinius/issues/356
[8] - http://github.com/evanphx/rubinius/issues/347
[9] - mailto:mongrel-unicorn@rubyforge.org
[a] - mailto:unicorn@bogomips.org
|
|
Since we accidentally dropped open_args a while back, nothing
seems to have broken :x So apparently MRI preserves it for us,
and test/unit/test_util.rb agrees.
|
|
Creating File objects while iterating ObjectSpace for File
objects may hit subtle bugs. It may only be safe in MRI, and
even then it's not behavior that sounds sane to rely on. So
stop doing it.
|
|
It can be useful to track down problems with
|
|
No need for extra checks when we're just doing read_nonblock.
We'll also avoid reallocating a 16K buffer every time we sleep,
we can just reuse the buffer the workers normally use to process
request.
|
|
IO#reopen in Rubinius seems to munge the O_APPEND flag when passed a
path, however passing an actual IO object. However, at the system call
level, everything is the same.
ref: http://github.com/evanphx/rubinius/issues/347
|
|
...than "test ?r" and "test ?w"
Not everybody comes from a Unix shell programming background,
even though they *should* ;)
|
|
Rack::Lint in Rack 1.1.0 does not require a "close" method for
env["rack.logger"], and we never explicitly close our logger,
either. This more easily allows the use of alternative
Logger-like implementations such as SyslogLogger.
|
|
While second nature to myself, stderr_path may be an
overlooked configuration parameter for some users. Also,
add a minimal sample configuration file that is shorter
and hopefully less intimidating to new users.
|
|
This middleware allows configurable out-of-band garbage
collection outside of the normal request/response cycle.
It offers configurable paths (to only GC on expensive actions)
and intervals to limit GC frequency.
It is only expected to work well with Unicorn, as it would
hurt performance on single-threaded servers if they
have keepalive enabled. Obviously this does not work well
for multi-threaded or evented servers that serve multiple
clients at once.
|
|
Modern version of Unicorn have working_directory available and
should use that instead.
|
|
Starting with this release, we'll always load Rack up front at
startup.
Previously we had complicated ways to avoid loading Rack until
after the application was loaded to allow the application to
load an alternate version of Rack. However this has proven too
error-prone to be worth supporting even though Unicorn does not
have strict requirements on currently released Rack versions.
If an app requires a different version of Rack than what Unicorn
would load by default, it is recommended they only install that
version of Rack (and no others) since Unicorn does not have any
strict requirements on currently released Rack versions.
Rails 2.3.x users should be aware of this as those versions are
not compatible with Rack 1.1.0.
If it is not possible to only have one Rack version installed
"globally", then they should either use Isolate or Bundler and
install a private version of Unicorn along with their preferred
version of Rack. Users who install in this way are recommended
to execute the isolated/bundled version of Unicorn, instead of
what would normally be in $PATH.
Feedback/tips to mailto:mongrel-unicorn@rubyforge.org from
Isolate and Bundler users would be greatly appreciated.
|
|
It's too complicated and error-prone to allow apps to use a
different version of Rack than the one Unicorn would otherwise
use by default.
If an app requires a different version of Rack than what Unicorn
would load by default, it is recommended they only install that
version of Rack (and no others) since Unicorn does not have any
strict requirements on currently released Rack versions.
If it is not possible to only have one Rack version installed
globally, then they should either use Isolate or Bundler and
install a private version of Unicorn along with their preferred
version of Rack. Users who install in this way are recommended
to execute the isolated/bundled version of Unicorn, instead of
what would normally be in $PATH.
Feedback/tips to mailto:mongrel-unicorn@rubyforge.org from
Isolate and Bundler users would be greatly appreciated.
|
|
Deployments that suspend or hibernate servers should no longer
have workers killed off (and restarted) upon resuming.
For Linux users of {raindrops}[http://raindrops.bogomips.org/]
(v0.2.0+) configuration is easier as raindrops can now
automatically detect the active listeners on the server
via the new Unicorn.listener_names singleton method.
For the pedantic, chunked request bodies without trailers are no
longer allowed to omit the final CRLF. This shouldn't affect
any real and RFC-compliant clients out there. Chunked requests
with trailers have always worked and continue to work the same
way.
The rest are mostly small internal cleanups and documentation
fixes. See the commit logs for full details.
|
|
This is useful as a :listeners argument when setting up
Raindrops::Middleware (http://raindrops.bogomips.org/),
as it can be done automatically.
|
|
* maint:
unicorn 0.97.1 - fix HTTP parser for Rainbows!/Zbatery
http: negative/invalid Content-Length raises exception
|
|
This release fixes a denial-of-service vector for derived
servers exposed directly to untrusted clients.
This bug does not affect most Unicorn deployments as Unicorn is
only supported with trusted clients (such as nginx) on a LAN.
nginx is known to reject clients that send invalid
Content-Length headers, so any deployments on a trusted LAN
and/or behind nginx are safe.
Servers affected by this bug include (but are not limited to)
Rainbows! and Zbatery. This bug does not affect Thin nor
Mongrel, as neither got the request body filtering treatment
that the Unicorn HTTP parser got in August 2009.
The bug fixed in this release could result in a
denial-of-service as it would trigger a process-wide assertion
instead of raising an exception. For servers such as
Rainbows!/Zbatery that serve multiple clients per worker
process, this could abort all clients connected to the
particular worker process that hit the assertion.
|
|
Trying to fix this issue again, as it seems to have been broken
again.
|
|
There is no need to be using autoload except for HttpResponse
which depends on Rack (which we want to load as late as
possible).
|
|
This will help ensure we use the same version of Rack the
application uses and avoid loading conflicting/incompatible
versions.
|
|
A bunch of small fixes related to startup/configuration and hot
reload issues with HUP:
* Variables in the user-generated config.ru files no longer
risk clobbering variables used in laucher scripts.
* signal handlers are initialized before the pid file is
dropped, so over-eager firing of init scripts won't
mysteriously nuke a process.
* SIGHUP will return app to original state if an updated
config.ru fails to load due to {Syntax,Load}Error.
* unicorn_rails should be Rails 3 compatible out-of-the-box
('unicorn' works as always, and is recommended for Rails 3)
* unicorn_rails is finally "working_directory"-aware when
generating default temporary paths and pid file
* config.ru encoding is the application's default in 1.9,
not forced to binary like many parts of Unicorn.
* configurator learned to handle the "user" directive outside
of after_fork hook (which will always remain supported).
There are also various internal cleanups and possible speedups.
|
|
It's part of the standard Ruby library and will always be loaded
by various modules (Rack::Utils, Tmpdir) so there's no point in
deferring it.
|
|
Allowing the "user" directive outside of after_fork reduces the
cognitive overhead for folks that do not need the complexity of
*_fork hooks. Using Worker#user remains supported as it offers
fine-grained control of user switching.
|
|
Do not assume the user wants config.ru to be Encoding::BINARY
for 1.9.
|
|
This lets us reuse code for Zbatery and Rainbows!, too.
|
|
It's a waste of memory bandwidth to do memcpy() when we know
Unicorn::HttpParser (via rb_str_resize()) will allocate new
memory for the string for us. An empty String is "free",
as we've already paid the Object cost regardless.
|
|
We'll use struct members exclusively from now on instead of
throwing ivars into the mix. This allows us to _unofficially_
support direct access to more members easily. Unofficial
extensions may include the ability to splice(2)/tee(2) for
better performance.
This also makes our object size smaller across all Ruby
implementations as well, too (helps Rainbows! out).
|
|
The temporary paths we create to mimic script/server-emulation
did not work when working_directory was used. Now we defer
path creation until after working_directory is bound.
|
|
no point in using "next" here
|
|
Copy-on-write will always invalidate it regardless, and
the first request is likely to be slow for any app.
|
|
This should make it easier to reuse code in derivative
servers like Rainbows! and Zbatery. Unfortunately, we
can't depend on Rack::Builder/Rack::Server yet since
Rack 1.1 just got them and notable frameworks (like
Rails 2.3.x) do not fully work with Rack 1.1 yet).
This also fixes subtle issue with config.ru files that could
have variables that conflict with the Unicorn-specific
namespace (this bug still affects "unicorn_rails", which
could use some reworking as well).
|
|
If preload_app is true and Unicorn is HUP-ed with a bad
config.ru, then it would be possible to have Unicorn in a bad
state and constantly throw 500 errors.
We now detect syntax and load errors since they're likely to
appear in modified Rackup files, and will restore the original
app if reloading failed.
|
|
Earlier elements of a Struct (in both Ruby and C) are faster
to access, so put more-often accessed elements like :app first.
This does not noticeably affect most applications, but may
matter to some micro benchmarks somewhere...
|
|
This prevents trigger-happy init scripts from reading the pid
file (and thus sending signals) to a not-fully initialized
master process to handle them.
This does NOT fix anything if other processes are sending
signals prematurely without relying on the presence of the pid
file. It's not possible to prevent all cases of this in one
process, even in a purely C application, so we won't bother
trying.
We continue to always defer signal handling to the main loop
anyways, and signals sent to the master process will be
deferred/ignored until Unicorn::HttpServer#join is run.
|
|
This constant hasn't been in active use in our Ruby code for
ages now. All HTTP header constraints are defined in the
C/Ragel HTTP parser and we have tests for them, so there's
no need to repeat ourselves.
|
|
There may be some large-ish internal changes for 0.97.0
|
|
This release includes small changes for things allowed by Rack
1.1. It is also now easier to detect if daemonized process
fails to start. Manpages received some minor updates as well.
Rack 1.1 allowed us to make the following environment changes:
* "rack.logger" is now set to the "logger" specified in
the Unicorn config file. This defaults to a Logger
instance pointing to $stderr.
* "rack.version" is now at [1,1]. Unicorn remains
compatible with previous Rack versions if your app
depends on it.
While only specified since Rack 1.1, Unicorn has always exposed
"rack.input" in binary mode (and has ridiculous integration
tests that go outside of Ruby to prove it!).
|
|
* rack-1.1:
http_response: disallow blank, multi-value headers
local.mk.sample: use rack-1.1.0
bump "rack.version" env to [1,1]
set env["rack.logger"] for applications
|
|
The HeaderHash optimizations in Rack 1.1 interact badly with
Rails 2.3.5 (and possibly other frameworks/apps) which set
multi-value "Set-Cookie" headers without relying on the proper
methods provided by Rack::Utils.
While this is an issue with Rails not using properly, there
may be similar apps that make this mistake and Rack::Lint
does not guard against it.
Rack-ML-Ref: <20100105235845.GB3377@dcvr.yhbt.net>
|
|
Inspection of the MRI source reveals that IO#sync=true only
appears to only apply for writes. Though it could eventually
make sense to disable read buffering by setting IO#sync=true,
it does not appear to happen.
Of course we never read from $stdin anyways....
|
|
Rainbows! does not yet know about ready_pipe, and will probably
not know about it until Unicorn 0.97.0
|
|
When using multiple listeners, the log messages can be
potentially misleading as to which listener fails to bind:
Before:
INFO -- : unlinking existing socket=/tmp/unicorn.sock
INFO -- : listening on addr=/tmp/unicorn.sock fd=3
unicorn/socket_helper.rb:110:in `initialize': Permission denied - bind(2) (Errno::EACCES)
After:
INFO -- : unlinking existing socket=/tmp/openxdms.sock
INFO -- : listening on addr=/tmp/openxdms.sock fd=3
FATAL -- : error adding listener addr=0.0.0.0:84
unicorn/socket_helper.rb:110:in `initialize': Permission denied - bind(2) (Errno::EACCES)
|
|
Rather than erroring out with a non-descript EOFError,
show a warning message telling users to check the logs
instead.
Reported-by: Iñaki Baz Castillo mid=200912281350.44760.ibc@aliax.net
|
|
Otherwise the original spawner process may not notice the close
as it's still being shared by workers. While we're at it, avoid
confusing the original spawner by using readpartial instead of
sysread.
|