| Date | Commit message (Collapse) |
|---|
|
|
|
Do not assume the user wants config.ru to be Encoding::BINARY
for 1.9.
|
|
|
|
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 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.
|
|
..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.
|
|
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...
|
|
This allows config.ru to specify listener and
stuff before we setup the application.
|
|
Combining command-line and config file options in a reasonable
manner has and always will be a painful experience.
|
|
This resurrects old code from Mongrel to wrap the Rails
Dispatcher for older versions of Rails. It seems that
Rails >= 2.2.0 support Rack, but only >=2.3 requires it.
I'd like to support Rails 1.2.x for a while, too.
|
|
Loading Rails (or at least config/environment)
will already load its version of Rack, duh!
This also prevents a double-require of Rack
causing redefined Rack::VERSION errors.
|
|
This was broken in the last commit (d1ff8c5):
start libifying common launcher code
|
|
The daemonization logic between unicorn and unicorn_rails
scripts can definitely be shared.
Again: our daemonization logic is slightly non-standard since
our executables are designed to run in APP_ROOT/RAILS_ROOT and
not "/" like "normal" UNIX daemons.
|
|
This should just run inside RAILS_ROOT out-of-the-box. No
config.ru is needed (but we'll use one if it's detected).
This has slightly different semantics than script/server
and the normal "unicorn" script (which has "rackup"-like)
semantics. It tries to combine the best of both worlds,
but do not consider the command-line option interface
to be stable by any means.
|