System-install defaults to RVM ruby, not system ruby #1110

mipearson opened this Issue Sep 13, 2012 · 3 comments


None yet
3 participants

On Ubuntu 10.04, system ruby is REE using Ubuntu packages from


  • Install RVM system-wide using curl -L | sudo bash -s stable
  • Install a Ruby using RVM as a regular user (in this case it was ruby-1.9.3-p194)
  • Log out, or re-boot the system
  • rvm info and ruby -v both show 1.9.3, not the system REE 1.8.7

I can understand why this behaviour is convenient, but it is an unfortunate surprise when installing RVM on a production system, especially as for us it exposed itself when a system init script ran something (in this case Jenkins) and that then ran Ruby and couldn't find its gems.

If you do not believe this behaviour should be changed, I believe that a warning should be placed in the documentation (similar to the umask warning already there).


richo commented Sep 13, 2012

I think potentially it's the heuristic for system ruby at fault, I don't recall seeing this behaviour before.

@ghost ghost assigned richo Sep 13, 2012


mpapis commented Sep 13, 2012

this is because first installed ruby is made default, it can be avoided by running RVM in binary mode:

command rvm install 1.9.3

also you can remove the default with:

rvm alias delete default

finally you can add system ruby to RVM and make it default:

rvm use system
rvm mount $(which ruby) -n system-ree
rvm alias create default ext-system-ree

ext is prefix for existing rubies mounted into RVM.

@mipearson let me know if none of those tree is an option for you, or if there are any errors with them.

@mpapis mpapis closed this Sep 13, 2012

@mpapis This issue is that RVM does this by default, when there's no expectation that it should. It's a nod to convenience, which works well for a developer machine (where continual interactivity means you generally know which interpreter you're using) but can cause problems for a system-wide install.

It violates the principle of least surprise.

Our particular discovery of this issue was relatively benign: I rebooted our test machine, jenkins ran from init, and we had test failures as the 'default' ruby had changed. It took me a short while to figure out that I was seeing stacktraces from 1.9.1 directories, not 1.8, and then a bit of a wild goose chase as I tried to work out whether I had an errant script or .profile changing the interpreter for me. I was quite surprised to find that RVM was doing this for me.

I don't really want to think about what would have happened had we needed to restart our actual production machine.

As above, if you don't want to lose the convenience of this measure on a default install, I'd really appreciate it if you added a note about this behaviour to the documentation. You've done the same with the g+w umask, which is to be commended.

@mpapis mpapis reopened this Sep 13, 2012

@mpapis mpapis closed this in 7a5f3b2 Sep 13, 2012

@ghost ghost assigned mpapis Sep 13, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment