Allied Technique Blog

uninitialized constant BackgrounDRb

Andrew Muia — Sat, 18 Apr 2009 09:23:36 +0000

Over the course of its lifespan, Backgroundrb has understandly transformed as new features and enhancements are implemented. However, if you are an earlier adopter, you might run into issues if you have a earlier version of backgroundrb and subsequently install newer versions of the dependencies that backgroundrb relies on.

I ran into this issue when migrating a legacy codebase onto a new CentOS 5.2 server. After copying over the codebase to the new server, I proceed to install all the required gems and fired up mongrel_cluster, which worked fine. However, upon attempting to start backgroundrb, the following errors were registered in the backgroundrb server log.

activesupport-2.0.2/lib/active_support/dependencies.rb:478:in `const_missing’: uninitialized constant BackgrounDRb::MasterWorker::BinParser (NameError)

from /current/vendor/plugins/backgroundrb/server/lib/master_worker.rb:148:in `post_init’

from /lib/ruby/gems/1.8/gems/packet-0.1.15/lib/packet/packet_connection.rb:25:in `invoke_init’

from /lib/ruby/gems/1.8/gems/packet-0.1.15/lib/packet/packet_core.rb:334:in `decorate_handler’

from /lib/ruby/gems/1.8/gems/packet-0.1.15/lib/packet/packet_core.rb:78:in `accept_connection’

from /lib/ruby/gems/1.8/gems/packet-0.1.15/lib/packet/packet_core.rb:220:in `handle_external_messages’

from /lib/ruby/gems/1.8/gems/packet-0.1.15/lib/packet/packet_core.rb:196:in `handle_read_event’

from /lib/ruby/gems/1.8/gems/packet-0.1.15/lib/packet/packet_core.rb:192:in `each’

from /lib/ruby/gems/1.8/gems/packet-0.1.15/lib/packet/packet_core.rb:192:in `handle_r

It took me a while to figure out what the matter was, but eventually, comparing the gem versions in the old and new servers, I noticed that the original packet gem was 0.1.5 and the new one was 0.1.15. And seeing that packet is where the error originated, I uninstalled 0.1.15 and replaced with it 0.1.5

$> gem uninstall packet

$> gem install packet -v=0.1.5

And surely enough, with the older packet gem installed, backgroundrb server started up fine. I suppose a long term solution would be to upgrade to the latest version of backgroundrb but that would require refactoring all the current workers. I choose instead to live to fight another day.

Installing ruby-xslt gem on CentOS 5.2

Andrew Muia — Fri, 17 Apr 2009 18:41:53 +0000

Ruby-xlst is one of those gems that has been known to throw curve balls during the installation process. This is usually because the gem has dependencies on libraries that are typically not installed on a system by default. On CentoOS 5.2 the following sequence of commands should do the trick

$> yum install libxml2-devel libxslt libxslt-devel

$> gem install ruby-xslt

The first command uses yum to installed the required libxml2 and libxslt libraries. Once this is done, you can then install the gem.

Setting Global Environment Variables in CentOS

Andrew Muia — Fri, 17 Apr 2009 01:52:17 +0000

The easiest way to set an environment variable in CentOS is to use export as in

$> export JAVA_HOME=/usr/java/jdk.1.5.0_12

$> export PATH=$PATH:$JAVA_HOME

However, variables set in such a manner are transient i.e. they will disappear the moment you exit the shell. Obviously this is not helpful when setting environment variables that need to persist even when the system reboots.

In such cases, you need to set the variables within the system wide profile. In CentOS (I’m using v5.2), the folder /etc/profile.d/ is the recommended place to add customizations to the system profile.

For example, when installing the Sun JDK, you might need to set the JAVA_HOME and JRE_HOME environment variables. In this case:

Create a new file called java.sh

vim /etc/profile.d/java.sh
Within this file, initialize the necessary environment variables

export JRE_HOME=/usr/java/jdk1.5.0_12/jre
export PATH=$PATH:$JRE_HOME/bin

export JAVA_HOME=/usr/java/jdk1.5.0_12
export JAVA_PATH=$JAVA_HOME

export PATH=$PATH:$JAVA_HOME/bin

Now when you restart your machine, the environment variables within java.sh will be automatically initialized (checkout /etc/profile if you are curious how the files in /etc/profile.d/ are loaded) .

PS: If you want to load the environment variables within java.sh without having to restart the machine, you can use the source command as in:

$> source java.sh