unicorn/reexec/bundler/cap deploy issue

Eric Wong normalperson at yhbt.net
Sat Jan 2 19:25:44 EST 2010


skaar <skaar at waste.org> 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


More information about the mongrel-unicorn mailing list