Date | Commit message (Collapse) |
|
This fixes a long-standing bug in the output of "unicorn_rails"
where the program name was missing.
(cherry picked from commit 096afc1a8e958cc09b4ce8b3bfe76ce056c7ed69)
|
|
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
|
|
|
|
|
|
This lets us reuse code for Zbatery and Rainbows!, too.
|
|
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.
|
|
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]
|
|
`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
|
|
We can get by with one less lambda in the loader
|
|
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.
|
|
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 allows config.ru files to be shared by rackup and
unicorn without errors.
|
|
This reverts commit 4414d9bf34f162a604d2aacc765ab1ca2fc90404.
|
|
This reverts commit e66ab79b8b5bc5311c750bf03868a7b2574f4ea1.
Conflicts:
bin/unicorn
|
|
Unicorn will always continue to run in the directory it started
in, it does not chdir to "/". Since the default start_ctx[:cwd]
is symlink-aware, this should not be a problem for
Capistrano-deployed applications.
|
|
This is a followup to 11172f9bdcc7c57c9ae857a8088e49527a953fa1
|
|
This allows LOAD_PATH modifications via the command-line
(via -I or -rubygems on the command-line).
|
|
As opposed to doing this in the shell, this allows the files to
be reopened reliably after rotation.
While we're at it, use $stderr/$stdout instead of STDERR/STDOUT
since they seem to be more favored.
|
|
Some applications do not handle loading before forking
out-of-the-box very gracefully, this starts adding support
to build the Rack(-ish) application later in the process.
|
|
Doesn't seem to make a difference for 1.8
but shows up in 1.9...
|
|
It's confusing with the lowercase "-p" option which is more
common for developers to use. PID files are only needed for
production deployments, and those should be using config files
anyways.
|
|
Ensure the output fits in a standard ANSI terminal so it's easy
to read for all users regardless of what interface they're
working from.
|
|
Since not all rackup command-line options can be supported by
Unicorn, disable this gross hack to avoid potentially
unpredictable or undefined behavior. config.ru will not be able
to specify the config file for unicorn-specific options; but the
unicorn-specific config files themselves will be allowed to
override the default config.ru location.
|
|
This allows Unicorn to be constantly started in symlink
paths such as the ones Capistrano creates
(e.g. "/u/apps/$app/current")
|
|
This adds a bunch of execution tests that require the "unicorn"
binary to be in PATH as well as rack being directly
"require"-able ("rubygems" will not be loaded for you). The
tester is responsible for setting up PATH and RUBYLIB
appropriately.
|
|
Daemonization only happens once at initial startup and is less
intrusive than traditional daemonize routines: we do not chdir,
set umask, or redirect/close STDOUT/STDERR since those are
doable via other config options with Unicorn (and the Unicorn
"config file" is just Ruby).
STDIN has no business being open on a daemon (and can be
dangerous to close if using certain buggy third-party libs).
|
|
Along with worker process management. This is nginx-style
inplace upgrading (I don't know of another web server that does
this). Basically we can preserve our opened listen sockets
across entire executable upgrades.
Signals:
USR2 - Sending USR2 to the master unicorn process will cause
it to exec a new master and keep the original workers running.
This is useful to validate that the new code changes took place
are valid and don't immediately die. Once the changes are
validated (manually), you may send QUIT to the original
master process to have it gracefully exit.
HUP - Sending this to the master will make it immediately exec
a new binary and cause the old workers to gracefully exit.
Use this if you're certain the latest changes to Unicorn (and
your app) are ready and don't need validating.
Unlike nginx, re-execing a new binary will pick up any and all
configuration changes. However listener sockets cannot be
removed when exec-ing; only added (for now).
I apologize for making such a big change in one commit, but once
I got the ability to replace the entire codebase while preserving
connections, it was too tempting to continue working.
So I wrote a large chunk of this while hitting
the unicorn-hello-world app with the following loop:
while curl -vSsfN http://0:8080; do date +%N; done
_Zero_ requests lost across multiple restarts.
|