Forum: Mongrel Mongrel_Cluster unable to access OCI8 library

Hi,

I'm able to run a ROR application in a Red Hat Enterprise Linux 4.4
environment, as long as I start my mongrel_cluster via the command line:

[chris@localhost ~]$ mongrel_cluster_ctl start

I take a look at the two mongrel_rails processes that were just created:

[chris@localhost log]$ ps -ef | grep mongrel
chris     4781     1  5 05:55 ?        00:00:02 /usr/local/bin/ruby
/usr/local/bin/mongrel_rails start -d -e production -a 0.0.0.0 -c
/home/chris/kitry/FDS_Server --user chris --group chris -p 4001 -P
log/mongrel.4001.pid -l log/mongrel.4001.log
chris     4784     1  5 05:55 ?        00:00:02 /usr/local/bin/ruby
/usr/local/bin/mongrel_rails start -d -e production -a 0.0.0.0 -c
/home/chris/kitry/FDS_Server --user chris --group chris -p 4002 -P
log/mongrel.4002.pid -l log/mongrel.4002.log

_____

Now, if I turn my mongrel_cluster into a service, which starts up at
boot time, my two mongrel_rails processes look identical, EXCEPT for the
PRIORITY LEVEL (5 by hand, 0 as a service):

[chris@localhost ~]$ ps -ef | grep mongrel
chris     2759     1  0 06:04 ?        00:00:02 /usr/local/bin/ruby
/usr/local/bin/mongrel_rails start -d -e production -a 0.0.0.0 -c
/home/chris/kitry/FDS_Server --user chris --group chris -p 4001 -P
log/mongrel.4001.pid -l log/mongrel.4001.log
chris     2762     1  0 06:04 ?        00:00:02 /usr/local/bin/ruby
/usr/local/bin/mongrel_rails start -d -e production -a 0.0.0.0 -c
/home/chris/kitry/FDS_Server --user chris --group chris -p 4002 -P
log/mongrel.4002.pid -l log/mongrel.4002.log

Unfortunately, this time, my application logs the following error
message:

LoadError (Oracle/OCI libraries could not be loaded: libclntsh.so.11.1:
cannot open shared object file: No such file or directory -
/usr/local/lib/ruby/site_ruby/1.8/i686-linux/oci8lib.so):
...
...

What could be causing the processes to correctly read the library file
in the first situation, but not in the second? Both are run by the same
user, in the same group. Maybe my "ps -ef" command is insufficient for
identifying all differences between the processes; I'm neither a Linux
nor a ROR expert...

Thanks,

Chris.

Just a quick thought Chris.   Whenever I've seen this happen it's been
because the process starting the mongrel does not have the required
Oracle environment variables set.  In my case this includes
LD_LIBRARY_PATH, which points to the Oracle libraries the error
message refers to.  A quick comparison between your environment vars
and the boot-time process environment vars would be useful.

regards

Greg

Hi Greg,

Yes indeed, I set LD_LIBRARY_PATH in user "chris"'s .bashrc file:

export 
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/oracle/11.1.0.1/client/lib

But since the processes run as the same user, I thought it would be OK.

Where should I set this variable instead, and by the way, how do I list 
the boot-time environment variables? As you can see, I'm not much of a 
Linux guru...

I appreciate your help,

Chris.

.bashrc runs for interactive shells only.

To see your full set of interactive env vars enter:

env

or

env | sort


You could view and set env vars in the script that is called at boot
time to start the mongrels.

Inside that script you can examine the process's environment variables
(echo $LD_LIBRARY_PATH  to the log) and set them using the same syntax
as in the .bashrc.

I expect you will also have to set some other Oracle-related env vars
- grep for ORACLE amongst your env vars to see what you are using
interactively.

All this should be pretty straightforward to your Oracle DBA if you
have one around.

One thing I have done with success when using daemon tools to manage
my mongrels is to put the Oracle environment variables in a wrapper
script that then calls the mongrel start command.

When I run as user, my .bashrc has the following line:

source
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle_env.sh

At the server, my mongrel_rails script sets the ORACLE_HOME variable
(zealots, beware, this hack is really ugly):

more /usr/local/bin/mongrel_rails
#!/usr/local/bin/ruby
#
# This file was generated by RubyGems.
#
# The application 'mongrel' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'rubygems'

version = ">= 0"

ENV['ORACLE_HOME'] = 
'/usr/lib/oracle/xe/app/oracle/product/10.2.0/server'

if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
   version = $1
   ARGV.shift
end

gem 'mongrel', version
load 'mongrel_rails'


# EOF


Ugly but works nicely :)

Cheers,

filipe

On Thu, 2 Oct 2008, Greg Clarke wrote:

>
>
>>
>> Posted via http://www.ruby-forum.com/.
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

filipe {
  @              icewall.org
  GPG         1024D/A6BA423E
  http://filipe.icewall.org/
}

On Wed, Oct 01, 2008 at 07:27:31PM -0700, Cynthia Kiser wrote:
> One thing I have done with success when using daemon tools to manage
> my mongrels is to put the Oracle environment variables in a wrapper
> script that then calls the mongrel start command.

You could also use envdir: http://cr.yp.to/daemontools/envdir.html

Thank you all for your help. I ended up setting my LD_LIBRARY_PATH in a 
new file called /etc/profile.d/oracle_libs.sh, and that solved my 
problem.

Setting the environment variable inside the mongrel_rails script also 
worked, but the solution above allows me to use SQL*Plus as well.

Cheers,

Chris.

Actually, I've had to do both... So my problem was actually solved by 
adding LD_LIBRARY_PATH to the mongrel_rails script.