Recipe fails on STDERR: sh: source: not found ---- End output of source /etc/profile.d/rvm.sh && rvm jruby-1.6.0@global gem env gempath ---- Ran source /etc/profile.d/rvm.sh && rvm jruby-1.6.0@global gem env gempath returned 127

[narkisr]

The recipe fails when trying to install the bundler gem (this happens also on 1.9.2 not just jruby)

[Sat, 02 Apr 2011 14:02:52 +0000] ERROR: rvm_gem[bundler](/home/ronen/chef-meta/external/cookbooks/rvm/recipes/default.rb:51:in `from_file') had an error:
Expected process to exit 0, but it exited with 127
---- Begin output of source /etc/profile.d/rvm.sh && rvm jruby-1.6.0@global gem env gempath ----
STDOUT:
STDERR: sh: source: not found
---- End output of source /etc/profile.d/rvm.sh && rvm jruby-1.6.0@global gem env gempath ----

[fnichol]

Hi there, are you running chef as non-root? Right now I was searching for a profile to source based on that assumption. I'll add a fallback to $HOME/.rvm/scripts/rvm which should do the trick.

[narkisr]

No Im actually running chef-solo as root, I am using zsh if that makes a difference, ill give the fallback a try

Thanks!

[narkisr]

Ok iv found the issue, it does seem to be related to the fact that my default shell is zsh

see http://www.ruby-forum.com/topic/203002

the fix is to use:

gem_binary "/bin/bash -c 'source #{profile}' && rvm #{ruby_string} gem"

Since source is bash specific feature,

Iv sent you a pull request
Ronen

[fnichol]

Looks like you tracked it down and pull request fix appears good.

[narkisr]

Thanks again

[wsc]

Having problems related to this fix:

STDOUT: 
STDERR: sh: rvm: not found

The problem is that

won't work because it is executing rvm.sh in its own process, which then exits without affecting the environment of the subsequent rvm command. Working on it now, should have more info on what works in an hour or two.

[wsc]

Reverting to the old code:
source /etc/profile.d/rvm.sh && rvm ruby-1.9.2-p180@global gem env gempath
causes a source: command not found error for me because Vagrant runs my chef-solo cookbooks using sudo.

The problem with passing the entire command to bash -c is that we're just hacking gem_package to return a binary path with the right environment script prepended: we can't quote what gets appended, in this case env gempath.

An additional problem is that this provider is being invoked to install global gems, so we need RVM's rvm gemset use global to set GEM_HOME and GEM_PATH. We can accomplish this by setting GEM_HOME directly:
gem_binary %{GEM_HOME=#{node[:rvm][:root_path]}/gems/#{ruby_string} gem}

This causes another problem: gem will use the system Rubygems instead of the RVM Rubygems. So:
gem_binary %{GEM_HOME=#{node[:rvm][:root_path]}/gems/#{ruby_string} #{node[:rvm][:root_path]}/rubies/#{normalize_ruby_string(new_resource.ruby_string)}/bin/gem}

However, this still fails for me:
[default] [Tue, 03 May 2011 17:11:10 +0000] ERROR: rvm_gem[bundler] (/tmp/vagrant-chef/cookbooks-0/rvm/recipes/default.rb:50:in from_file') had an error:
No such file or directory - GEM_HOME=/usr/local/rvm/gems/ruby-1.9.2-p180@global GEM_PATH=/usr/local/rvm/gems/ruby-1.9.2-p180@global /usr/local/rvm/rubies/ruby-1.9.2-p180/bin/gem env gempath`

I'm not sure what's wrong. If I run it from ssh it returns the correct path, so I assume it has something to do with the environment that Chef is running under. I might spend more time to look at it later but for now I'm just going to disable gem installs.

[codykrieger]

I'm trying to get this to work with Vagrant as well, and I've got the same issue.

[fnordfish]

Here is a workaround (for the vagant issues): https://github.com/fnordfish/vagrant-soup/blob/master/roles/ruby_devel.rb

It basically makes sure that bundler is installed as a global gem

[codykrieger]

The workaround works for me! Awesome.

[wsc]

Works for me too!

[fnichol]

@wsc that's exactly what I thought would happen while sub-processing the sourcing of rvm.sh. I'm hoping to get a few minutes at home tonight to tie this off, or dig deeper :)

I ran into problems with RVM and pre-made vagrant boxes which I eventually solved for myself in a vagrant_extras recipe. Is it worth adding some minor helpers in the rvm cookbook to help vagrant work better out of the gate? I'm starting to think that could be helpful.

[codykrieger]

Another issue (with JRuby specifically) after the workaround is implemented: #16

Normal rubies like REE, 1.9.2, etc. work fine.

UPDATE: scratch that, I'm an idiot.

[wsc]

Ah, here's why it works regardless of the bash -c: hashicorp/vagrant#327

"all sudo requests are now loaded in a "login" shell so that if system-wide RVM is setup, then the bash_profile should be loaded to setup ruby to execute the proper RVM-managed ruby."

[fnichol]

@wsc, right I remember reading that pull request and not totally understanding it at the time :) I'm doing some experimenting with a more traditional Chef provider for this resource. That would allow me to get at the shell_out!() method call and also perhaps a way to override the behavior of the built in gem_resource.

Out of curiosity, what is everyone's target chef environments? I'm primarily testing things out with the stock lucid32 Vagrant image and chef 0.9.12. My day-to-day vagrant and production VMs are Ubuntu 10.10 x32 with chef 0.9.16 (at the moment). Just curious if there are any platform differences we should account for.

[codykrieger]

Similar here: stock lucid64 Vagrant image and whatever the latest version of chef is.

[fnichol]

@fnordfish the reason your fix works is the second chef run, the chef gem is found in the default rvm ruby's global gemset. Without it, the system ruby is effectively "hidden" under the RVM default. Another possible solution that I am using is this chef-solo wrapper script it gets put higher in PATH at /usr/local/bin/chef-solo and calls the system (apt installed) ruby's chef gem which was provided by the vagrant base box. Mind bender :)

[fnichol]

I tried an alternate approach with this one. I created a new old school-style provider for rvm_gem which extends Chef::Provider::Package::Rubygems. This way we can get full control over the the shelled out gem command. So far in testing things are looking pretty good. Can someone try it out and confirm? If all looks good we can put this issue to bed again.

[fnichol]

I'm going to be brave and assume that we're all resolved. If not, then please re-open.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.