Date | Commit message (Collapse) |
|
This feature is on hold for now, since it never really took
off and kgio-monkey is more-or-less abandoned. I'm not looking
forward to supporting OpenSSL unless there's interest.
This was mainly intended as an experiment to deal with a bad
hardware/firmware situation on a LAN I have. It allowed SSL
to abort on corrupt packets.
|
|
We shouldn't leave processes running after the test.
|
|
Otherwise these tests fail if we start using IO#autoclose=true
on Ruby 1.9 (and also if we use IPv6 sockets for tests).
|
|
This fixes the -N (a.k.a. --no-defaut-middleware) option, which
was not working. The problem was that Unicorn::Configurator::RACKUP
is cleared before the lambda returned by Unicorn.builder is run,
which means that checking whether the :no_default_middleware option
was set from the lambda could not detect anything. This patch copies
it to a local variable that won't get clobbered, restoring the feature.
[ew: squashed test commit into the fix, whitespace fixes]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
|
|
On FreeBSD 9.0, "wc -l" emits leading whitespace, so
filter it through tr -d '[:space:]' to eliminate it.
|
|
On FreeBSD 9.0, "wc -c" emits leading whitespace, so
filter it through tr -d '[:space:]' to eliminate it.
This is commit 8a6117a22a7d01eeb5adc63d3152acf435cd3176
in rainbows.git
|
|
"date +%s" is not in POSIX (it is in GNU, and at least FreeBSD
9.0, possibly earlier). The Ruby equivalent should be
sufficiently portable between different Ruby versions.
This change was automated via:
perl -i -p -e 's/date \+%s/unix_time/' t/*.sh
This is commit 0ba6fc3c30b9cf530faf7fcf5ce7be519ec13fe7
in rainbows.git
|
|
POSIX already stipulates tee(1) must be unbuffered. I think my
decision to use utee was due to my being misled by a bug in
older curl where -N did not work as advertised (but --no-buffer
did).
N.B. we don't use tee in unicorn tests, this just matches
commit cbff7b0892148b037581541184364e0e91d2a138 in rainbows
|
|
Once a connection is hijacked, we ignore it completely and leave
the connection at the mercy of the application.
|
|
Rack 1.5.0 (protocol version [1,2]) adds support for
hijacking the client socket (removing it from the control
of unicorn (or any other Rack webserver)).
Tested with rack 1.5.0.
|
|
In the case where preload_app is true, delay binding new
listeners until after loading the application.
Some applications have very long load times (especially Rails
apps with Ruby 1.9.2). Binding listeners early may cause a load
balancer to incorrectly believe the unicorn workers are ready to
serve traffic even while the app is being loaded.
Once a listener is bound, connect() requests from the load
balancer succeed until the listen backlog is filled. This
allows requests to pile up for a bit (depending on backlog size)
before getting rejected by the kernel. By the time the
application is loaded and ready-to-run, requests in the
listen backlog are likely stale and not useful to process.
Processes inheriting listeners do not suffer this effect, as the
old process should still be capable of serving new requests.
This change does not improve the situation for the
preload_app=false (default) use case. There may not be a
solution for preload_app=false users using large applications.
Fortunately Ruby 1.9.3+ improves load times of large
applications significantly over 1.9.2 so this should be less of
a problem in the future.
Reported via private email sent on 2012-06-29T22:59:10Z
|
|
It's too much overhead to keep Rails-specific tests working,
especially when it's hauling in an ancient version of SQLite3.
Since Rails 3 has settled down with Rack and unicorn_rails is
unlikely to need changing in the future, we can drop these
tests.
|
|
These should be made executable for ease-of-understanding and
consistency, regardless of whether we actually execute them.
|
|
Previously we relied on implicit socket shutdown() from the
close() syscall. However, some Rack applications fork()
(without calling exec()), creating a potentially long-lived
reference to the underlying socket in a child process. This
ends up causing nginx to wait on the socket shutdown when the
child process exits.
Calling shutdown() explicitly signals nginx (or whatever client)
that the unicorn worker is done with the socket, regardless of
the number of FD references to the underlying socket in
existence.
This was not an issue for applications which exec() since
FD_CLOEXEC is always set on the client socket.
Thanks to Patrick Wenger for discovering this. Thanks to
Hongli Lai for the tip on using shutdown() as is done in
Passenger.
ref: http://mid.gmane.org/CAOG6bOTseAPbjU5LYchODqjdF3-Ez4+M8jo-D_D2Wq0jkdc4Rw@mail.gmail.com
|
|
This seems required for TLSv1.2 under OpenSSL 1.0.1
|
|
We're only allowed 108 bytes for Unix domain sockets.
mktemp(1) usually generates path names of reasonable length
and we rely on it anyways.
|
|
The output of SHA1 command-line tools is too unstable and
I'm more comfortable with Ruby 1.9 encoding support than
I was in 2009.
Jeremy Evans noted the output of "openssl sha1" has
changed since I last used it.
|
|
expr on OpenBSD uses a basic regular expression (according to
re_format(7)), which doesn't support +, only *.
Acked-by: Eric Wong <normalperson@yhbt.net>
|
|
We throw up some fake SSL certs for testing
|
|
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! (in whatever form) should also be able to
use it.
|
|
Backtraces are now formatted properly (with timestamps) and
exceptions will be logged more consistently and similar to
Logger defaults:
"#{exc.message} (#{e.class})"
backtrace.each { |line| ... }
This may break some existing monitoring scripts, but errors
will be more standardized and easier to check moving forward.
|
|
"app error" is more correct, and consistent with Rainbows!
|
|
rescuing from SystemExit and exit()-ing again is ugly, but
changes made to lower stack depth positively affect _everyone_
so we'll tolerate some ugliness here.
We'll need to disable graceful exit for some tests, too...
|
|
Just in case we break anything
|
|
Rainbows! wants to be able to lower this eventually...
|
|
"wait" needs to be done in the outside shell because
the subshell could still be exiting when we grep.
|
|
There's an HTTP status code allocated for it in
<http://www.iana.org/assignments/http-status-codes>, so
return that instead of 400.
|
|
This was broken since v3.3.1[1] since nginx relies on a closed
socket (and not Content-Length/Transfer-Encoding) to detect
a response completion. We have to close the client socket
before invoking GC to ensure the client sees the response
in a timely manner.
[1] - commit b72a86f66c722d56a6d77ed1d2779ace6ad103ed
|
|
No need to use an ancient Rack now that we've dropped Rails
2.3.x tests. We need to remember that Rack 1.1.0 doesn't
support input#size.
|
|
This causes conflicts with ports clients may use in
the ephemeral range since those do not hold FS locks.
This reverts commit e597e594ad88dc02d70f7d3521d0d3bdc23739bb.
Conflicts:
test/test_helper.rb
|
|
Duh...
|
|
Response bodies may capture the block passed to each
and save it for body.close, so don't close the socket
before we have a chance to call body.close
|
|
More config bloat, sadly this is necessary for Rainbows! :<
|
|
Since modern machines have more memory these days and
clients are sending more data, avoiding potentially slow
filesystem operations for larger uploads can be useful
for some applications.
|
|
This has been broken since 2.0.x
Internal cleanups sometimes have unintended consequences :<
|
|
In case a request sends the header and buffer as one packet,
TeeInput relying on accounting info from StreamInput is harmful
as StreamInput will buffer in memory outside of TeeInput's
control.
This bug is triggered by calling env["rack.input"].size or
env["rack.input"].rewind before to read.
|
|
This will help ensure we trap our own errors properly
in the future.
|
|
oops :x
|
|
This allows users to override the current Rack spec and disable
the rewindable input requirement. This can allow applications
to use less I/O to minimize the performance impact when
processing uploads.
|
|
We need to ensure the old worker is reaped before sending
new requests intended for the new worker.
|
|
If a configuration directive is set at startup and later
unset, it correctly restores the original default value
as if it had never been set in the first place.
This applies to the majority of the configuration values with
a few exceptions:
* This only applies to stderr_path and stdout_path when
daemonized (the usual case, they'll be redirected to
"/dev/null"). When NOT daemonized, we cannot easily redirect
back to the original stdout/stderr destinations.
* Unsetting working_directory does not restore the
original working directory where Unicorn was started.
As far as we can tell unsetting this after setting it is
rarely desirable and greatly increases the probability of
user error.
|
|
This may be useful for some apps that wish to drain the body
before acquiring an app-wide lock. Maybe it's more useful
with Rainbows!...
|
|
Automation is nice, the makefile needs some cleanup
|
|
We'll be using more of Isolate in development.
|
|
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
|
|
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.
|
|
No code changes needed, thankfully.
|
|
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
|