Trouble upgrading rubygems.

A little more fiddling and I discovered that when I installed vim-full an incomplete install of ruby 1.8 was also placed on the system.  Aptitude thought ruby was installed, but it wasn’t.  Hence two posts ago me saying that Ubuntu was weird and I had to reinstall ruby.

A second problem with what I installed was that the command ‘ruby -v’ wouldn’t work but ‘ruby1.8 -v’ would give the desired result.  Ruby had been installed everywhere prefixed with ‘1.8′.  Makes sense as it allows you to have multiple versions of ruby installed at once, but things like mongrel won’t work as they are expecting to find ‘ruby’ not ‘ruby1.8′.  Meaning I’d have to create a bunch of symbolic links like below to solve the problem.

ln -snf /usr/bin/ruby1.8 /usr/bin/ruby

I don’t like that as it’s fails the don’t compile source rule as the moment I upgrade to ruby 1.9 I’ve got to remember to manually change all those symbolic links.  A bit more digging and I discovered that there are packages that do this for me, so in the end I’ve run the following to install ruby on Ubuntu:

apt-get install ruby libruby irb ruby1.8-dev libopenssl-ruby libreadline-ruby ri rdoc

Package dependencies mean that all the previous packages I was trying to install are also installed.  Nice.

Next up RubyGems.  RubyGems uses the yaml and zlib libraries, as noted here,  but it’s package unfortunately hasn’t had this included in it’s setup, so the following is required for an install:

apt-get install rubygems libyaml-ruby libzlib-ruby

This only installs version 0.9.4-4 though so you have to run the self update task:

gem update --system

Should be pretty simple, but thirty minutes after running this it’s still only telling me the following:

Updating RubyGems...
Bulk updating Gem source index for: http://gems.rubyforge.org

A quick google revels that this can happen in virtualised systems (ie zen which slicehost use) when you don’t give them enough system resource.  My server only has 256mb of ram and the gem process quickly ate 85% of it then stopped doing anything.

I might leave it running while I go watch the rugby.  If it’s still essentially hung after the match I’ll probably upgrade the server to a 512 instance and try again.  Then upon success, hopefully, I’ll downgrade back to 256.  Obviously in a real life produciton environment this wouldn’t be an acceptable practice, but then i wouldn’t be using a server with 256mb of ram either.

No related posts.

This entry was posted in Performance Project and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

2 Comments

  1. Josh Martin
    Posted July 28, 2008 at 7:07 pm | Permalink

    I am having a similar issues with a 256mb system, were you able to achieve the update and install gems?

  2. nahum
    Posted July 28, 2008 at 9:07 pm | Permalink

    Yeah. I’m just actually writing up that blog post now. Ran through real quick without a hitch, so I installed Rails while I was there with double the ram. Afterwords I downgraded back to 256 so I’d only be charged a day at the 512 rate.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*
  •  

  • About Nahum Wild

    I'm a High Performance Website Consultant specialising in Ruby on Rails deployments. In this blog I cover common problems I've seen and provide insight on optimisation techniques.

  • Recommend Me

    Follow me on Twitter