skaar wrote:
> Hi Eric,
>
> we've run into an issue with Unicorn's reexec, when the rails app is
> using Bundler and we deploy into dated release directories. Still not
> sure what the correct fix is for this, but what happens is that bundler
> modifies (acutally prefixes) PATH/RUBYOPT and when you reexec unicorn
> these are passed along to the new master process - and Bundler will
> again append to the PATH/RUBYOBT.
>
> This becomes more of a problem when you deploy with capistrano and
> include SIGUSR2 restart of your unicorn. And effectively it will attempt
> to load all Bundler vendor/bundler_gems/environment.rb for all deploys
> since unicorn was first started - and if you have, say, a keep only 5
> releases strategy, you will soon get failures when a bundler
> environment.rb file in RUBYOPT has been shifted out.
>
> I'm still not sure what the right solution is (to modify unicorn, the
> unicorn.rb config file or to address it in bundler),
Hi skaar,
Does having this in the Unicorn config file work for you?
stash_env = %w(PATH RUBYOPT).map { |x| [ x, ENV[x] ] }
before_exec do |_|
stash_env.each { |(k,v)| ENV[k] = v }
end
It's more generic and less surprising for people that (may) want
to change environment variables on upgrades:
> but the following
> patch does it brute force in unicorn and introduce the assumption that
> a reexec should take the same PATH/RUBYOPT variables as the initial
> invokation of the unicorn process (using a similar strategy as with
> PWD):
Early versions of Unicorn actually captured the entire ENV at startup
and restored it before exec. I felt it was too heavy-handed since I
figured any process that changed its environment variables has good
reason to do so, so I've been trying to leave as much alone as
possible...
--
Eric Wong
___
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
