Prev: RPM Query
Next: Firefox image zoom is bad
From: C. on 1 Dec 2009 09:28
Hi all,

This one has me confused.

I'm trying to run a script via atd. Along with some other stuff, this
script tries to run sqlplus - but fails. From the email from atd:

sqlplus: error while loading shared libraries: libsqlplus.so: cannot
open shared object file: No such file or directory

This file is in the directory /usr/lib/oracle/10.2.0.4/client/lib

in /etc/profile.d/ I have oracle.sh:

LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.4/client/lib:${LD_LIBRARY_PATH}
TNS_ADMIN=/usr/local/nagios/var/probedata
export LD_LIBRARY_PATH TNS_ADMIN

At the command prompt, LD_LIBRARY_PATH is set correctly, and sqlplus
runs OK.
If I run printenv via atd, then TNS_ADMIN is there, and set correctly,
but LD_LIBRARY_PATH is not!

I've got a workaround by adding the dir to ld.so.conf (and running
ldconfig) but its bugging me why this is happenning. The only
explanation I can come up with is that 'at' or 'atd' is tripping out
the variable. According the man page it shouldn't do this:

The working directory,
the environment (except for the variables TERM, DISPLAY and _)
and the
umask are retained from the time of invocation.

Anybody any ideas?

C.
From: Richard Kettlewell on 1 Dec 2009 12:49
"C." <colin.mckinnon(a)gmail.com> writes:

> I'm trying to run a script via atd. Along with some other stuff, this
> script tries to run sqlplus - but fails. From the email from atd:
>
> sqlplus: error while loading shared libraries: libsqlplus.so: cannot
> open shared object file: No such file or directory
>
> This file is in the directory /usr/lib/oracle/10.2.0.4/client/lib
>
> in /etc/profile.d/ I have oracle.sh:
>
> LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.4/client/lib:${LD_LIBRARY_PATH}
> TNS_ADMIN=/usr/local/nagios/var/probedata
> export LD_LIBRARY_PATH TNS_ADMIN
>
> At the command prompt, LD_LIBRARY_PATH is set correctly, and sqlplus
> runs OK.
> If I run printenv via atd, then TNS_ADMIN is there, and set correctly,
> but LD_LIBRARY_PATH is not!
>
> I've got a workaround by adding the dir to ld.so.conf (and running
> ldconfig) but its bugging me why this is happenning. The only
> explanation I can come up with is that 'at' or 'atd' is tripping out
> the variable. According the man page it shouldn't do this:
>
> The working directory,
> the environment (except for the variables TERM, DISPLAY and _)
> and the
> umask are retained from the time of invocation.
>
> Anybody any ideas?

at is a setuid program, and the runtime linker deletes certain
variables from the environment of setuid programs. LD_LIBRARY_PATH is
one of them.

--
http://www.greenend.org.uk/rjk/
From: Big and Blue on 1 Dec 2009 20:03
C. wrote:

> Anybody any ideas?

Don't set such environment variables globally - just set them for the
application. So run oracle tools, such as sqlplus, through an interlude
script that sets the environment for oracle. That way you don't have
LD_LIBRARY_PATH set for every other dynamic executable you run.

And, if you install Oracle and run the final stage, which does a local
relink, it will set the RPATH/RUNPATH entry in the tools etc. so that you
don't need to use LD_LIBRARY_PATH at all. At least it does when I do it.

--
Just because I've written it doesn't mean that
either you or I have to believe it.
From: C. on 2 Dec 2009 11:31
On Dec 2, 1:03 am, Big and Blue <N...(a)dsl.pipex.com> wrote:
> C. wrote:
> > Anybody any ideas?
>
> Don't set such environment variables globally - just set them for the
> application.  So run oracle tools, such as sqlplus, through an interlude
> script that sets the environment for oracle.  That way you don't have
> LD_LIBRARY_PATH set for every other dynamic executable you run.
>
> And, if you install Oracle and run the final stage, which does a local
> relink, it will set the RPATH/RUNPATH entry in the tools etc. so that you
> don't need to use LD_LIBRARY_PATH at all.  At least it does when I do it.
>

Yes - thats a much nicer way of solving the problem - thanks.

C.
From: C. on 2 Dec 2009 11:34
On Dec 1, 5:49 pm, Richard Kettlewell <r...(a)greenend.org.uk> wrote:
> "C." <colin.mckin...(a)gmail.com> writes:
<snip>
>
> at is a setuid program, and the runtime linker deletes certain
> variables from the environment of setuid programs.  LD_LIBRARY_PATH is
> one of them.
>

Thanks - yes, LD_LIBRARY_PATH + setuid gives me lots of background
material in Google.

C.
 |  Next  |  Last
Pages: 1 2
Prev: RPM Query
Next: Firefox image zoom is bad