On Sep 9, 2010, at 4:28 PM, Eirik Dentz Sinclair wrote:
> First off thanks very much for all the hard work on unicorn. Alas, we've
> encountered an issue where unicorn fails to spawn new workers that have
> loaded the incoming revision on a capistrano deploy. I'm not entirely sure
> the issue is due to unicorn as it appears that bundler was responsible for a
> similar issue in the past:
> http://github.com/carlhuda/bundler/issues/issue/259/#comment_180830
>
> But presumably bundler has corrected that issue and any help in sorting out
> the issue would be greatly appreciated.
>
> [snip]
>
> The deployed versioned directory is 20100830230613
> The incoming versioned directory is 20100902192111
I think I may have run into a potentially related bundler+unicorn+capistrano
issue just today!
With bundler+unicorn the shell environment does not really get cleared between
USR2 restarts/forkings, which was the cause of the aforementioned GitHub
ticket... PATH/RUBYOPT would just get infinitely appended to by bundler, and
unicorn is happy to let you do whatever with the environment
The bug I found today cropped up while upgrading from rails 2.3.8 to rails
2.3.9 -- on deploy the new unicorn master would die with "hey you've already
loaded rails 2.3.8!". Weird.
Some quick debugging showed my BUNDLE_GEMFILE environment variable was
referencing a Gemfile from a (very) old capistrano release.... I'm actively
debugging it now. I'm also using preload_app=true which might have contributed.
Eirik, can you confirm any similar "old release" weirdnesses by dumping the ENV
in your unicorn.rb's before_exec / before_fork?
STDERR.puts ENV.inspect
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
