| Date | Commit message (Collapse) |
|---|
|
* PATH_INFO (aka REQUEST_PATH) increased to 4096 (from 1024).
This allows requests with longer path components and matches
the system PATH_MAX value common to GNU/Linux systems for
serving filesystem components with long names.
* Apps that fork() (but do not exec()) internally for background
tasks now indicate the end-of-request immediately after
writing the Rack response.
Thanks to Hongli Lai, Lawrence Pit, Patrick Wenger and Nuo Yan
for their valuable feedback for this release.
|
|
These should be made executable for ease-of-understanding and
consistency, regardless of whether we actually execute them.
|
|
The previous REQUEST_PATH limit of 1024 is relatively small and
some users encounter problems with long URLs. 4K is a common
limit for PATH_MAX on modern GNU/Linux systems and REQUEST_PATH
is likely to translate to a filesystem path name.
Thanks to Nuo Yan <yan.nuo@gmail.com> and Lawrence Pit
<lawrence.pit@gmail.com> for their feedback on this issue.
ref: http://mid.gmane.org/CB935F19-72B8-4EC2-8A1D-5084B37C09F2@gmail.com
|
|
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
|
|
Found via rdoc-spellcheck
|
|
* Stale pid files are detected if a pid is recycled by processes
belonging to another user, thanks to Graham Bleach.
* nginx example config updates thanks to to Eike Herzbach.
* KNOWN_ISSUES now documents issues with apps/libs that install
conflicting signal handlers.
|
|
This latest version of kgio improves portability to
FreeBSD-based systems.
|
|
In some cases, EPERM may indicate a real configuration problem,
but it can also just mean the pid file is stale.
|
|
Jeffrey Yeung confirmed this issue on the mailing list.
ref: <E8D9E7CCC2621343A0A3BB45E8DEDFA91C682DD23D@CRPMBOXPRD04.polycom.com>
|
|
This adds a little more flexibility to the nginx config,
especially as protocols (e.g. SPDY) become more prevalent.
Suggested-by: Eike Herzbach <eike@herzbach.net>
|
|
From: Eike Herzbach <eike@herzbach.net>
|
|
If unicorn doesn't get terminated cleanly (for example if the machine
has its power interrupted) and the pid in the pidfile gets used by
another process, the current unicorn code will exit and not start a
server. This tiny patch fixes that behaviour.
Acked-by: Eric Wong <normalperson@yhbt.net>
|
|
The GPLv3 is now an option to the Unicorn license. The existing GPLv2
and Ruby-only terms will always remain options, but the GPLv3 is
preferred.
Daemonization is correctly detected on all terminals for development
use (Brian P O'Rourke).
Unicorn::OobGC respects applications that disable GC entirely
during application dispatch (Yuichi Tateno).
Many test fixes for OpenBSD, which may help other *BSDs, too.
(Jeremy Evans).
There is now _optional_ SSL support (via the "kgio-monkey"
RubyGem). On fast, secure LANs, SSL is only intended for
detecting data corruption that weak TCP checksums cannot detect.
Our SSL support is remains unaudited by security experts.
There are also some minor bugfixes and documentation
improvements.
Ruby 2.0.0dev also has a copy-on-write friendly GC which can save memory
when combined with "preload_app true", so if you're in the mood, start
testing Unicorn with the latest Ruby!
|
|
Ruby 2.0.0dev is the future and includes a CoW-friendly GC,
so we shall encourage folks to give Ruby 2.0.0dev a spin.
|
|
We don't need it because we don't test old Rails with bleeding edge Ruby.
|
|
I doubt anybody would attempt to run ancient, unsupported versions
of Rails on the latest (unreleased, even) versions of Ruby...
|
|
Again, we test with the latest version.
|
|
Trying to ensure things always work with the latest version.
|
|
:<
|
|
It's the latest and greatest version, so ensure everything
works with it.
|
|
We need to be sure we don't barf on this header.
|
|
No need to duplicate logic here
|
|
It's possible for a SIGUSR1 signal to be received in the
worker immediately before calling IO.select. In that case,
do not clutter logging with IOError and just process the
reopen log request.
|
|
Oops :x
|
|
Even LANs can break or be unreliable sometimes and socket
disconnect messages get lost, which means we fall back to
the global (kill -9) timeout in Unicorn.
While the default global timeout is much shorter (60s) than
typical TCP timeouts, some HTTP application dispatches take much
I/O or computational time (streaming many gigabytes), so the
global timeout becomes ineffective.
Under Linux, sysadmins are encouraged to lower the default
net.ipv4.tcp_keepalive_* knobs in sysctl. There should be
similar knobs in other operating systems (the default keepalive
intervals are usually ridiculously high, too high for anything).
When the listen socket has SO_KEEPALIVE set, the flag should be
inherited by accept()-ed sockets.
|
|
We favor low latency and consistency with the Unix socket
behavior even with TCP.
|
|
We should always be testing with the newest available versions
to watch for incompatibilities, even if we don't /require/ the
latest ones to run.
|
|
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.
|
|
You can listen on 0.0.0.0, but trying to connect to it doesn't work
well on OpenBSD.
Acked-by: Eric Wong <normalperson@yhbt.net>
|
|
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>
|
|
There's no practical difference between a timeout of 30 days and
68 years from an HTTP server standpoint.
POSIX limits us to 31 days, actually, but there could be
rounding error with floats used in Ruby time calculations and
there's no real difference between 30 and 31 days, either...
Thanks to Jeremy Evans for pointing out large values will throw
EINVAL (on select(2) under OpenBSD with Ruby 1.9.3 and
RangeError on older Rubies.
|
|
We throw up some fake SSL certs for testing
|
|
[ew: we need to explicitly enable GC if it is disabled
and respect applications that disable GC]
Acked-by: Eric Wong <normalperson@yhbt.net>
|
|
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.
|
|
This prevents the stopping of all workers by SIGWINCH if you're
using a windowing system that will 'exec' unicorn from a process
that's already in a process group.
Acked-by: Eric Wong <normalperson@yhbt.net>
|
|
Since unicorn is designed to be deployed behind nginx (or
similar), X-Forwarded-* headers are common and Rack applications
may blindly trust spoofed X-Forwarded-* headers. UnXF provides
a central place for managing that trust by using rpatricia.
|
|
The old comment was confusing. We only zero the tick counter
when forking because application loading can take a long time.
Otherwise, it's always updated.
ref: http://mid.gmane.org/20110908191352.GA25251@dcvr.yhbt.net
|
|
There is no need to keep extra hashes or Proc objects around in
the heap.
|
|
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:
https://www.gnu.org/licenses/quick-guide-gplv3.html
http://gplv3.fsf.org/rms-why.html
ref: http://thread.gmane.org/gmane.comp.lang.ruby.unicorn.general/933
|
|
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:
http://unicorn.bogomips.org/Application_Timeouts.html
|
|
Hopefully this leads to fewer worker processes being killed.
|
|
We do it in the Ruby invocation or RUBYLIB.
|
|
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.
|
|
Oops!
|
|
* 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]
|
|
|
|
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.
|
|
Hopefully it points people towards the mailing list
|