Date | Commit message (Collapse) |
|
Note: `unicorn_rails' was only intended for Rails <= 2.x projects
in the old days.
Fixes: 5985dd50a9bd7238 ("Support default_middleware configuration option")
From: Jeremy Evans <code@jeremyevans.net>
cf. https://bogomips.org/unicorn-public/20190306055734.GC61406@jeremyevans.local/
Signed-off-by: Eric Wong <e@80x24.org>
[ew: commit message]
|
|
This allows for the equivalent of the
-N/--no-default_middleware command line option to be
specified in the configuration file so it doesn't
need to be specified on the command line every time
unicorn is executed.
It explicitly excludes the use of -N/--no-default_middleware
as an embedded configuration option in the rackup file, by
ignoring the options after ARGV is parsed.
In order to allow the configuration method to work, have
the lambda that Unicorn.builder returns accept two arguments.
Technically, only one argument is needed for the HttpServer
instance, but I'm guessing if the lambda accepts a single
argument, we expect that to be a rack application instead
of a lambda that returns a rack application.
The command line option option to disable default middleware
will take precedence over the unicorn configuration file option
if both are present.
For backwards compatibility, if the lambda passed to
HttpServer accepts 0 arguments, then call it without
arguments.
[ew: fix precedence for arity checking in build_app!
configurator: ensure -N is respected when set in command-line]
|
|
Literal regexps cost over 450 bytes of memory per-site and
unnecessary use of them costs memory in places where raw execution
speed does not matter. Nowadays, we can rely on String#end_with?
(introduced in 1.8.7) for improved readability, too.
|
|
Users may confuse '-p' with the (to-be-deprecated) '-P/--pid'
option, leading to surprising behavior if a pathname is passed as a
port, because String#to_i would convert it to zero, causing:
TCPServer.new(host, port = 0)
to bind to a random, unused port.
|
|
This would prevent Unicorn from adding default middleware,
as if RACK_ENV were always none. (not development nor deployment)
This should also be applied to `rainbows' and `zbatery' as well.
One of the reasons to add this is to avoid conflicting
RAILS_ENV and RACK_ENV. It would be helpful in the case
where a Rails application and Rack application are composed
together, while we want Rails app runs under development
and Rack app runs under none (if we don't want those default
middleware), and we don't really want to make RAILS_ENV
set to development and RACK_ENV to none because it might be
confusing. Note that Rails would also look into RACK_ENV.
Another reason for this is that only `rackup' would be
inserting those default middleware. Both `thin' and `puma'
would not do this, nor does Rack::Handler.get.run which is
used in Sinatra.
So using this option would make it work differently from
`rackup' but somehow more similar to `thin' or `puma'.
Discussion thread on the mailing list:
http://rubyforge.org/pipermail/mongrel-unicorn/2013-January/001675.html
Signed-off-by: Eric Wong <normalperson@yhbt.net>
|
|
There's absolutely no need to keep the OptionParser around in
worker processes.
|
|
This reduces the size of `caller` by 5 frames,
which should make backtraces easier-to-read, raising
exceptions less expensive, and reduce GC runtime.
|
|
|
|
It's more descriptive as to what environment we're setting
than "ENVIRONMENT".
|
|
These nasty hacks were breaking Rubinius compatibility.
This can be further cleaned up, too.
|
|
This fixes a long-standing bug in the output of "unicorn_rails"
where the program name was missing.
|
|
Rails 3 will automatically load it for us.
|
|
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
|
|
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.
|
|
This allows us to properly detect Rails 3 installations
in cases where config.ru is not present.
[ew: expanded commit message
fixed static file serving,
more flexible regexp for matching module ]
ref: mid.gmane.org/AANLkTiksBxIo_PFWoiPTWi1entXZRb7D2uE-Rl7H3lbw@mail.gmail.com
Acked-by: Eric Wong <normalperson@yhbt.net>
|
|
This should allow "unicorn_rails" to be used seamlessly
with Rails 3 projects which package config.ru for you.
|
|
|
|
"ru" is the preferred name in Unicorn.builder, so we'll
match that to make things easier to follow.
|
|
Do not assume the user wants config.ru to be Encoding::BINARY
for 1.9.
This is a followup to a4a8bf7604d1c15c5a8fb9cb6be37e8bccb32e52
|
|
This is to ensure there are no namespace inconsistencies
|
|
|
|
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.
|
|
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.
|
|
We'll use our Rails-only version of Unicorn.builder so
the lambda is safe without another binding.
|
|
The stock config/boot.rb file in a Rails 3 app is much lighter
and does not export any Rails/RAILS_* constants, so we'll wait
until we get config/environment.rb loaded.
|
|
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).
|
|
This behavior change also means our grandparent (launched
from a controlling terminal or script) will wait until
the master process is ready before returning.
Thanks to IƱaki Baz Castillo for the initial implementations
and inspiration.
|
|
|
|
Shells already expand '~' before the executables see it, and
relative paths inside symlinks can get set incorrectly to the
actual directory name, and not the (usually desired) symlink
name for things like Capistrano.
Since our paths are now unexpanded, we must now check the
"working_directory" directive and raise an error if the user
specifies the config file in a way that makes the config file
unreloadable.
|
|
It makes life easier for people writing config.ru files for use
with Rails.
|
|
This makes our RACK_ENV handling like our RAILS_ENV
handling for unicorn_rails, removing the redundant
local variable.
|
|
Although not currently part of the Rack specification,
ENV["RACK_ENV"] is at least a de facto standard. Some of the
popular Rack servers (Thin, Passenger) and frameworks (Merb,
Sinatra) already set or use it.
ML-Ref: <C7A9411D-CD40-4DA4-9CB3-6AA959D2D127@larsen.st>
Acked-by: Eric Wong <normalperson@yhbt.net>
[ew: setenv always, not just on CLI + commit message]
|
|
..but keep -P deprecated. --path is still useful for testing
ad-hoc changes when you don't want to commit your changes
permanently to a configuration file.
|
|
Since Unicorn config files are written in Ruby, setting
RAILS_RELATIVE_URL_ROOT should be possible (and even encouraged)
in the config file if it is done at all.
|
|
This matches the manpage and the rest of the documentation.
|
|
`unicorn` tries to mimic `rackup` on the command-line to ease
adoption. `unicorn_rails` tries to be somewhat like `rackup` as
well, but then also tries to be consistent with `script/server`
resulting some amount of confusion with regard to the
-P/(--path|--pid) switch. Outright removal of these switches
will probably not happen any time soon because we have
command-lines inherited across processes, but we can stop
advertising them.
Since our (Unicorn) config file format is fortunately consistent
between Rails and !Rails, recommend the "pid" directive be used
instead.
User interfaces are really, really tough to get right...
|
|
|
|
This ensures any string literals that pop up in *our* code will
just be a bag of bytes. This shouldn't affect/fix/break
existing apps in most cases, but most constants will always have
the "correct" encoding (none!) to be consistent with HTTP/socket
expectations. Since this comment affects things only on a
per-source basis, it won't affect existing apps with the
exception of strings we pass to the Rack application.
This will eventually allow us to get rid of that Unicorn::Z
constant, too.
|
|
Rack is autoload-based and so are we.
|
|
I've noticed rackup has been __END__-aware as of
7b6046b764eafd332b3b2d9d93b3915c425fae54 in Rack upstream
|
|
I've experienced occasional problems with this so it's
probably best to stay on the safe side.
|
|
It's pointless to support multiple instances of it since
this is per-process. However, the constant itself is now
modifiable if anybody needs to tweak things for reexecution
using a before_exec hook.
|
|
We can get by with one less lambda in the loader
|
|
There were some unnecessary lambdas in there
along with some repeated checks.
|
|
Just use the RAILS_RELATIVE_URL_ROOT variable to support it
since probably works on more versions of Rails. Since no
application I've ever deployed has ever used it, I'm not going
to bother supporting it for Rails <2.3, either.
|
|
This removes half-implemented support to disable static file
serving. People interested enough can provide their own
config.ru file to save some stat(2) syscalls, but extra
command-config options just complicate things.
|
|
Makes problems easier to solve if we dump the
exception...
|