Awhile back I upgraded the “rack” gem on one of our CentOS Linux servers that runs LiteSpeed and Ruby. The upgrade took the rack gem from rack version 1.0.0 to rack version 1.0.1. After upgrading the Rack gem I attempted to visit the site located on the server where the gem was updated only to receive a 503 error from LiteSpeed. During the troubleshooting process I looked at the LiteSpeed error logs and noticed errors that lead me back to the Rack gem I had just updated. Below I describe the error in more detail and what can be done to resolve the issue of rack-1.0.1.
When I installed MacPorts 1.8.2 on MacOS X 10.5.8, it automatically changed my PATH in my .bash_profile file. To fix the “rubygems (LoadError)” error message, I moved the “/opt/local/bin” from the beginning of the PATH to the end as follows:
rubygems.rb:578:in report_activate_error: RubyGem version error: rspec(1.1.11 not = 1.2.4) (Gem::LoadError)
Earlier when attempting to use request-log-analyzer on a new server I had just installed it on I got the error stated below. There are numerous updates to the gems I was using to fulfill all of the requirements of the request-log-analyzer gem. I went through and updated many of the gems until I ran into an issue with the hoe gem that required an update to rubygems. Once I upgraded rubygems everything worked properly without throwing any errors. I probably could have simply updated rubygems and things would have worked fine without upgrading all of the other gems it was complaining about.
Earlier when attempting to install the request-log-analyzer gem on a CentOS Linux server I ran into some issues. I noticed that on one server I was able to install the request-log-analyzer gem without issue but on another server running the same version of CentOS and Ruby as the first server the attempt to install request-log-analyzer returned an error. The error was that the gem required a newer version of another gem.
The Interactive Ruby Shell, or IRB, doesn’t have a way to clear all variables that I am aware of besides quitting irb and then restarting irb however you can simulate this by invoking subirbs. Subirbs are jobs underneath the main irb session that will allow you to work within irb on different code at the same time without having to stop irb and restart it. So you can load certain gems from the main irb session and not be required to reload them for each subirb. Below are some examples of how subirbs or irb jobs are used.