Lawrence Pit <[email protected]> wrote: > Hi Eric, > > At the top of my pastie http://pastie.org/1043347.txt you can see that > when I request of list of gems it mentions only unicorn v1.1.2 > > I also added the suggested logging to the before_fork block and I also > logged the unicorn version. Interesting output. First it runs the master > with Unicorn v1.1.2. But when I send a USR2 it exec'ed with a Unicorn > v1.1.1 for the new master. So yes, I still had a version lying around, > namely in the $APP_ROOT/vendor/bundler_gems dir. > > See also: http://pastie.org/1043487.txt > > It does do this though after a USR2: > > executing ["/usr/local/rvm/gems/ree-1.8.7-2010.02/bin/unicorn_rails", > "-D", "-E", "staging", "-c", > "/var/www/staging/current/config/unicorn/staging.rb"] > > I.e., it tries to exec exactly how I start unicorn. That unicorn_rails > binary in that path is definitely v1.1.2. So I don't quite understand > why the reexeced one is picking the version from the vendor/bundler_gems > dir.
It's probably loading 1.1.1 because of GEM_HOME/GEM_PATH being set. The "unicorn_rails"/"unicorn" wrappers just activates whatever gems it sees, and GEM_HOME/GEM_PATH can influence the wrapper. Managing RubyGems installations is still tricky :< > I need to play a bit more with this.. I'll probably have to change my > /etc/init.d/unicorn script so that it starts with the > vendor/bundler_gems version instead of a system-wide version :o I'll > get back to you.. Take a look at http://unicorn.bogomips.org/Sandbox.html According to Jamie, using "bundle exec unicorn_rails" is the correct way to go. -- Eric Wong _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
