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.
On Wed, Oct 01, 2008 at 07:27:31PM -0700, Cynthia K. 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.
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
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users
Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users
filipe {
@ icewall.org
GPG 1024D/A6BA423E
http://filipe.icewall.org/
}