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 }

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

Eric Wong

More information about the mongrel-unicorn mailing list