| Date | Commit message (Collapse) |
|---|
|
* commit 'v1.1.4':
unicorn 1.1.4 - small bug fix and doc updates
update Rails 3 tests to use Rails 3 final
avoid unlinking actively listening sockets
doc: update HACKING for documentation contributions
doc: update Sandbox document for Bundler
TUNING: more on socket buffer sizes
|
|
We no longer unlinking actively listening sockets upon startup
(but continue to unlink dead ones). This bug could trigger
downtime and nginx failures if a user makes an error and
attempts to start Unicorn while it is already running.
Thanks to Jordan Ritter for the detailed bug report leading to
this fix.
ref: http://mid.gmane.org/8D95A44B-A098-43BE-B532-7D74BD957F31@darkridge.com
There are also minor documentation and test updates pulled in
from master. This is hopefully the last bugfix release of the
1.1.x series.
|
|
Rails 3 is out, and requires no code changes on our end to work
(as far as our tests show :)
(cherry picked from commit da272fc48ffaa808456fe94dd7a3e01bc9799832)
|
|
While we've always unlinked dead sockets from nuked/leftover
processes, blindly unlinking them can cause unnecessary failures
when an active process is already listening on them. We now
make a simple connect(2) check to ensure the socket is not in
use before unlinking it.
Thanks to Jordan Ritter for the detailed bug report leading to
this fix.
ref: http://mid.gmane.org/8D95A44B-A098-43BE-B532-7D74BD957F31@darkridge.com
(cherry picked from commit 1a2363b17b1d06be6b35d347ebcaed6a0c940200)
|
|
We switched to RDoc 2.5.x long ago and this should clarify
some documentation preferences I have.
(cherry picked from commit 505a9e72d320fe3ae521ceb0f381c1c0f5ae4389)
|
|
Thanks to Lawrence Pit, Jamie Wilkinson, and Eirik Dentz Sinclair.
ref: mid.gmane.org/4C8986DA.7090603@gmail.com
ref: mid.gmane.org/5F1A02DB-CBDA-4302-9E26-8050C2D72433@efficiency20.com
(cherry picked from commit 1a75966a5d1a1f6307ed3386e2f91a28bbb72ca0)
|
|
While we've always unlinked dead sockets from nuked/leftover
processes, blindly unlinking them can cause unnecessary failures
when an active process is already listening on them. We now
make a simple connect(2) check to ensure the socket is not in
use before unlinking it.
Thanks to Jordan Ritter for the detailed bug report leading to
this fix.
ref: http://mid.gmane.org/8D95A44B-A098-43BE-B532-7D74BD957F31@darkridge.com
|
|
We switched to RDoc 2.5.x long ago and this should clarify
some documentation preferences I have.
|
|
Thanks to Lawrence Pit, Jamie Wilkinson, and Eirik Dentz Sinclair.
ref: mid.gmane.org/4C8986DA.7090603@gmail.com
ref: mid.gmane.org/5F1A02DB-CBDA-4302-9E26-8050C2D72433@efficiency20.com
|
|
Large buffers can hurt as well as help. And the difference
in real apps that do a lot of things other than I/O often
makes it not worth it.
(cherry picked from commit f9a7a19a361fd674bab4e2df7e0897015528bba7)
|
|
Large buffers can hurt as well as help. And the difference
in real apps that do a lot of things other than I/O often
makes it not worth it.
|
|
Rails 3 is out, and requires no code changes on our end to work
(as far as our tests show :)
|
|
These nasty hacks were breaking Rubinius compatibility.
This can be further cleaned up, too.
|
|
* 1.1.x-stable:
unicorn 1.1.3 - small bug fixes
make log reopens even more robust in threaded apps
update Rails3 tests to use 3.0.0rc2
make log reopens more robust in multithreaded apps
bin/*: more consistent --help output
SIGTTIN works after SIGWINCH
|
|
This release fixes race conditions during SIGUSR1 log cycling.
This bug mainly affects Rainbows! users serving static files,
but some Rack apps use threads internally even under Unicorn.
Other small fixes:
* SIGTTIN works as documented after SIGWINCH
* --help output from `unicorn` and `unicorn_rails` is more consistent
|
|
A follow-up to 4b23693b9082a84433a9e6c1f358b58420176b27
If multithreaded programming can be compared to juggling
chainsaws, then multithreaded programming with signal handlers
in play is akin to juggling chainsaws on a tightrope
over shark-infested waters.
(cherry picked from commit feab35fe531843066db3418598874cf9f9419614)
|
|
A follow-up to 4b23693b9082a84433a9e6c1f358b58420176b27
If multithreaded programming can be compared to juggling
chainsaws, then multithreaded programming with signal handlers
in play is akin to juggling chainsaws on a tightrope
over shark-infested waters.
|
|
No code changes needed, thankfully.
(cherry picked from commit 18968f6aff2fa5ba5a7e3e3d47c9cc05cd6c260d)
|
|
No code changes needed, thankfully.
|
|
IOError may occur due to race conditions as another thread
may close the file immediately after we call File#closed?
to check.
Errno::EBADF may occur in some applications that close a file
descriptor without notifying Ruby (or if two IO objects refer to
the same descriptor, possibly one of them using IO#for_fd).
(cherry picked from commit 4b23693b9082a84433a9e6c1f358b58420176b27)
|
|
This fixes a long-standing bug in the output of "unicorn_rails"
where the program name was missing.
(cherry picked from commit 096afc1a8e958cc09b4ce8b3bfe76ce056c7ed69)
|
|
IOError may occur due to race conditions as another thread
may close the file immediately after we call File#closed?
to check.
Errno::EBADF may occur in some applications that close a file
descriptor without notifying Ruby (or if two IO objects refer to
the same descriptor, possibly one of them using IO#for_fd).
|
|
This fixes a long-standing bug in the output of "unicorn_rails"
where the program name was missing.
|
|
These are minor changes to remove unnecessary loop nesting and
begin usage to reduce our code size and hopefully simplify
flow for readers.
|
|
Something is wrong if workers exit with a non-zero status,
so we'll increase the log level to help prevent people
from missing it.
|
|
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 f1d33c80dd6c5650f960f7087f4e08f809754d34)
|
|
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
|
|
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)
|
|
* 1.1.x-stable: (27 commits)
unicorn 1.1.2 - fixing upgrade rollbacks
unicorn 1.0.1 - bugfixes only
SIGHUP deals w/ dual master pid path scenario
launcher: do not re-daemonize when USR2 upgrading
SIGHUP deals w/ dual master pid path scenario
launcher: do not re-daemonize when USR2 upgrading
unicorn 1.1.1 - fixing cleanups gone bad :x
tee_input: fix constant resolution for client EOF
unicorn 1.1.0 - small changes and cleanups
cleanup "stringio" require
tee_input: safer record separator ($/) handling
prefer "[]" to "first"/"last" where possible
tee_input: safer record separator ($/) handling
socket_helper: disable documentation
socket_helper: cleanup FreeBSD accf_* detection
socket_helper: no reason to check for logger method
configurator: cleanup RDoc, un-indent
configurator: documentation for new accept options
socket_helper: move defaults to the DEFAULTS constant
doc: recommend absolute paths for -c/--config-file
...
|
|
This release is fixes 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.
|
|
* commit 'v1.0.1':
unicorn 1.0.1 - bugfixes only
SIGHUP deals w/ dual master pid path scenario
launcher: do not re-daemonize when USR2 upgrading
tee_input: safer record separator ($/) handling
|
|
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)
|
|
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)
|
|
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
|
|
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.
|
|
Unicorn::TeeInput constant resolution for Unicorn::ClientError
got broken simplifying code for RDoc. This affects users
of Rainbows! and Zbatery.
|
|
Noticed while hacking on a Zbatery-using application
(cherry picked from commit ac15513bb81a345cd12c67702a81a585b8b0514e)
|
|
Noticed while hacking on a Zbatery-using application
|
|
This is a small, incremental feature release with some internal
changes to better support upcoming versions of the Rainbows! and
Zbatery web servers. There is no need to upgrade if you're
happy with 1.0.0, but also little danger in upgrading.
There is one pedantic bugfix which shouldn't affect anyone
and small documentation updates as well.
|
|
"stringio" is part of the Ruby distro and we use it in multiple
places, so avoid re-requiring it.
(cherry picked from commit 0fea004ab093ec4f59d919915a505a136326bd8a)
|
|
"stringio" is part of the Ruby distro and we use it in multiple
places, so avoid re-requiring it.
|
|
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)
|
|
"[]" is slightly faster under Ruby 1.9 (but slightly
slower under 1.8).
(cherry picked from commit 5ece8c1c33f10e6496dfe5ae1d0d368293278d2d)
|
|
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)
|
|
"[]" is slightly faster under Ruby 1.9 (but slightly
slower under 1.8).
|
|
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 98c51edf8b6f031a655a93b52808c9f9b78fb6fa)
|