Date | Commit message (Collapse) |
|
We don't want to flood or monopolize freshmeat.
(cherry picked from commit 1ad510d645e0c84c8d352ac0deaeefa75240ea94)
|
|
There is no need to loop in the master_sleep method at all, as
the rest of the code is designed to function even on interrupted
sleeps.
This change is included as part of a larger cleanup in master.
(commit bdc79712e5ac53d39c51e80dfe50aff950e5053f)
|
|
In addition to SIGHUP, it should be possible to gradually bring
workers back up (to avoid overloading the machine) when rolling
back upgrades after SIGWINCH.
Noticed-by: Lawrence Pit
ref: http://mid.gmane.org/4C3F8C9F.2090903@gmail.com
(cherry picked from commit e75ee7615f9875db314a6403964e7b69a68b0521)
|
|
The first maintenance release of 1.0.x, this release is
primarily to fix a long-standing bug where the original PID file
is not restored when rolling back from a USR2 upgrade.
Presumably most upgrades aren't rolled back, so it took over a
year to notice this issue. Thanks to Lawrence Pit for
discovering and reporting this issue.
There is also a pedantic TeeInput bugfix which shouldn't affect
real apps from the 1.1.x series and a test case fix for OSX,
too.
|
|
As described in our SIGNALS documentation, sending SIGHUP to the
old master (to respawn SIGWINCH-ed children) while the new
master (spawned from SIGUSR2) is active is useful for backing
out of an upgrade before sending SIGQUIT to the new master.
Unfortunately, the SIGHUP signal to the old master will cause
the ".oldbin" pid file to be reset to the non-".oldbin" version
and thus attempt to clobber the pid file in use by the
to-be-terminated new master process.
Thanks to the previous commit to prevent redaemonization in the
new master, the old master can reliably detect if the new master
is active while it is reloading the config file.
Thanks to Lawrence Pit for discovering this bug.
ref: http://mid.gmane.org/4C3BEACF.7040301@gmail.com
(cherry picked from commit c13bec3449396b21795966101367838161612d61)
|
|
This was accidentally enabled when ready_pipe was developed.
While re-daemonizing appears harmless in most cases this makes
detecting backed-out upgrades from the original master process
impossible.
(cherry picked from commit 3f0f9d6d72cf17b34c130b86eb933bbc513b24b3)
|
|
Different threads may change $/ during execution, so cache it at
function entry to a local variable for safety. $/ may also be
of a non-binary encoding, so rely on Rack::Utils.bytesize to
portably capture the correct size.
Our string slicing is always safe from 1.9 encoding: both our
socket and backing temporary file are opened in binary mode,
so we'll always be dealing with binary strings in this class
(in accordance to the Rack spec).
(cherry picked from commit 1cd698f8c7938b1f19e9ba091708cb4515187939)
|
|
We do an extra check in the application dispatch to ensure
ENV['PWD'] is set correctly to match Dir.pwd (even if the
string path is different) as this is required for Capistrano
deployments.
These tests should now pass under OSX where /var is apparently
a symlink to /private/var.
|
|
There are only minor changes since 0.991.0.
For users clinging onto the past, MRI 1.8.6 support has been
restored. Users are strongly encouraged to upgrade to the
latest 1.8.7, REE or 1.9.1.
For users looking towards the future, the core test suite and
the Rails 3 (beta) integration tests pass entirely under 1.9.2
preview3. As of the latest rubinius.git[1], Rubinius support is
nearly complete as well.
Under Rubinius, signals may corrupt responses as they're being
written to the socket, but that should be fixable transparently
to us[4]. Support for the hardly used, hardly documented[2]
embedded command-line switches in rackup config (.ru) files is
is also broken under Rubinius.
The recently-released Rack 1.2.1 introduced no compatiblity
issues[3] in core Unicorn. We remain compatible with all Rack
releases starting with 0.9.1 (and possibly before).
[1] tested with Rubinius upstream commit
cf4a5a759234faa3f7d8a92d68fa89d8c5048f72
[2] lets avoid the Dueling Banjos effect here :x
[3] actually, Rack 1.2.1 is broken under 1.8.6.
[4] http://github.com/evanphx/rubinius/issues/373
|
|
|
|
This lets me use RSYNC=echo when testing/editing documentation
without actually publishing it.
|
|
test-lib handles variables named "*socket" (and "*fifo")
differently than ordinary variables.
|
|
Our fugly code can't handle embedded command-line options in
config.ru when using Rubinius yet. So add some related tests
to the ones marked RBX_SKIP that don't rely on embedded
command-line options.
|
|
As of rbx commit cf4a5a759234faa3f7d8a92d68fa89d8c5048f72,
most of the issues uncovered in our test suite are fixed.
|
|
This is fixed upstream in Rubinius by commit
b630ad9ddb4544a62e8e2282ba7dc59c4269bad7
|
|
While log reopening worked reliably for newly-created File
objects in the unit tests, the $stderr and $stdout handles that
get redirected did not get reopened reliably under Rubinius.
We work around this by relying on Rubinius internals and
directly setting the @path instance variable. This is harmless
for MRI and should be harmless for other any other Ruby
implementations we'll eventually support.
ref: http://github.com/evanphx/rubinius/issues/360
|
|
Rack 1.2 removed the +size+ method requirement, but we'll
still support it since Rack 1.2 doesn't _prohibit_ it, and
Rack 1.[01] applications will continue to exist for a while.
|
|
p114 probably had the most deployments of the 1.8.6 series,
and I encountered problems with p399 that don't seem to be
triggered with any other Rubies. 1.8.6 is mostly a lost
cause, but we shall avoid the rb_str_set_len() regression.
|
|
Rack 1.2 no longer requires "rack.input" objects respond
to size.
|
|
|
|
Ruby 1.9.2 no longer adds the current directory to $LOAD_PATH
automatically.
|
|
No point in having namespaces be classes when we never
create instances of them...
|
|
|
|
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.
|
|
|
|
|
|
We share the same array from the original bin/* down
into the Configurator.
|
|
While we're at it, inform people of why they might use
a symlink
|
|
... And make the gemspec do minor un-RDoc-ing
|
|
This makes the user (sysadmin in this case) more aware if the
upgrade fails or doesn't work as intended. This change could be
more useful for Rainbows! with its long-running responses.
|
|
This was commit abc207b2918606867094f2820bab58223e99aac4 from
rainbows.git
|
|
|
|
Don't try to redirect until we know our FIFO consumers are
ready for us. This only seems to happen with bash and not
ksh...
|
|
eval("...", TOPLEVEL_BINDING) is broken for us in Rubinius
(And our code is extremely nasty as well :x)
ref: http://github.com/evanphx/rubinius/issues/357
|
|
|
|
|
|
Rubinius now supports rb_str_set_len() and sets -fPIC.
We shouldn't check for rb_str_modify() since link-time detection
is broken under Rubinius and even 1.8.6 has rb_str_modify().
|
|
Rails 3 will automatically load it for us.
|
|
more tests may use it
|
|
|
|
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
|
|
shorter is better
|
|
It's a good idea to use a caching http_proxy to save bandwidth
when isolating gems for different Ruby versions.
|
|
We haven't started using isolate with Rubinius, yet,
but we may soon.
|
|
Our gemspec won't work without it
|
|
~/.gems is still shared, and we don't isolate
*that* often enough to matter
|
|
Rainbows! and Zbatery have long been upgraded to
pass options to us.
|
|
In case we have weird Rails 3 users who choose to ignore
config.ru, we'll be ready.
|
|
Ruby 1.9.2 no longer includes "." in $LOAD_PATH, so we need to
require using an explicit path. This issue only affected Rails
3 users who chose to run without the default config.ru, as the
config.ru generated by Rails 3 will call File.expand_path
in the same way.
|
|
We'll be adding more Rails 3 tests..
|