When I run cap deploy:update
I get the error below, indicating that bundle
is not found. When I run echo $PATH
from cap shell
the /var/lib/gems/1.9.1/bin
path which contains bundle is missing, however, this path is in both /etc/profile
and ~/.bashrc
. Anyone know how to solve this problem?
[192.168.10.100] executing command
*** [err :: 192.168.10.100] sh:
*** [err :: 192.168.10.100] bundle: not found
*** [err :: 192.168.10.100]
command finished in 25ms
failed: "sh -c 'bundle install --gemfile /data/www/apps/my_app/releases/201104
04163717/Gemfile --path /data/www/apps/my_apps/shared/bundle --deployment --qui
et --without development test'" on 192.168.10.100
To avoide such problem you should have most recent versions of RVM (currently it is 1.13.5) installed in both places: locally and on remote server.
Next, check if your deploy.rb has
require "rvm/capistrano"
require "bundler/capistrano"
This line is not needed anymore:
$:.unshift(File.expand_path('./lib', ENV['rvm_path']))
Hope this will help
Ok, I've recently had some experience with this. Looks like there are a couple of ways that this problem can be solved. First, you can determine if in fact the remote execution (via Capistrano) is what's messed up vs. the host itself. Looks like you've done this with the Capistrano remote shell:
$ cap shell
> echo $PATH
Good. I'll bet when you login to the machine and 'echo $PATH' there, the right stuff comes out... same here.
I've found two ways to fix this: One is to enable the environment execution in the remote host's ssh daemon. In theory this would work, but I didn't want to ask the sysadmin if it was ok to open this up. You basically edit the ssh configuration files to set the 'PermitUserEnvironment' to 'yes' and add the required environment settings to the deploy user's ~/.ssh/environment file -- your system-specific man pages are probably better than my trying to generalize.
I opted for what seems rather hackish, and has the drawback that it is global for all hosts you deploy the app to (so if your ruby / gems locations are different on different hosts, this won't work) -- but: I added the default_environment settings to the config/deploy.rb script:
set :default_environment, {
'PATH' => "/usr/local/bin:/bin:/usr/bin:/bin:/<ruby-dir>/bin",
'GEM_HOME' => '<ruby-dir>/lib/ruby/gems/1.8',
'GEM_PATH' => '<ruby-dir>lib/ruby/gems/1.8',
'BUNDLE_PATH' => '<ruby-dir>/lib/ruby/gems/1.8/gems'
}
AMMENDED: It isn't so 'hackish' if you consider the following:
- The environment-specific deploy scripts (deploy/foo.rb) can
override the default in deploy.rb
- PermitUserEnvironment hides the configuration deep in the
.ssh directory of the deploy user; :default_environment at
least exposes it in the checked-in sources.
This also solves the problem of not being able to do remote rake tasks, etc., via Capistrano. Be aware that the Capistrano gem, at least the version I have and with my deploy set up in the "standard" way, will install the gems into the /shared/bundle directory, which gets picked up by the app. The method I described requires a minimal subset of gems in the system directories referenced by the default environment so that the remote Capistrano commands can execute bundle, rake, etc.
You didn't say if you were using RVM (my solution doesn't); however, this solution is very close to one of the recommended RVM solutions. Alternately, you could just use the 'rvm/capistrano' solution; look for RVM Capistrano integration on the RVM website for more details.
Have you manually installed the bundler
gem on the remote box? You can't use the bundle
command or install any bundles until you do.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With