Bug 228019

You need to expand on steps 2 and 3.  Are you using a graphical environment? 
Are you logging in through the console?  If a graphical environment, what you
you typing 'echo $LD_LIBRARY_PATH' into -- a terminal window?  If
gnome-terminal, is it configured as a login terminal, etc..

I login with graphical screen. However, I often launch a termnal screen for
editing source code for programming projects. I like to use command line entry
for many tasks.

So gnome-terminal?

And is it configured as a login terminal?  What does 'shopt login_shell' say?

Created attachment 147798 [details]
output from ENV command to text file

 file created via ENV > env.txt

Sorry, I need to see the output of 'shopt login_shell'.

Created attachment 147936 [details]
shopt login_shell > shopt.txt

Would it be useful to see my /etc/profile file?

Robert, I have attempted to replicate the problem you have. I added the
following file called /etc/profile.d/set_ld_library_path.sh that contains :


export LD_LIBRARY_PATH="$HOME/libs/"



This results in my LD_LIBARY_PATH being set correctly. It is generally
recommended that you use the /etc/profile.d directory instead of editing the
/etc/profile file directly, but it still should work.

Are you using 'export' at all?

> login_shell    	off

When bash is not running as a login shell, it does not read /etc/profile.  So
bash is not at fault here.

From what I recall when this was reported before (ages ago), the login manager
is responsible for setting the profile.  Changing component and reassigning.

I am currently setting variables in the /etc/profile but will change my setup to
use profile.d as recommended. 

Robert can you attach your /etc/profile please?

Note, gnome-terminal shouldn't be executing a login shell (that would be wrong).
 Instead the startup scripts are ran through a login shell once (so you don't
get  things that only supposed to run at login, run every time you start a
terminal).

There have been bugs in the past with bash and ksh where they didn't work quite
right if argv[0] started with a hyphen (which means run a login shell).

I have two guesses on what could be going on:
1) you aren't putting export in front of LD_LIBRARY_PATH (as mentioned earlier
as a possibility
2) something else in the startup scripts is overwriting LD_LIBRARY_PATH to defaults

You don't have some stray export lines in ~/.bashrc or or ~/.bash_profile do
you?  Does LD_LIBRARY_PATH get successfully set for some users?

Created attachment 148007 [details]
/etc/profile

NOTE: all the PostgreSQL variables are exported correctly.
I will create script for /etc/profile.d later today and will check the results.

Again, because all variables in /etc/profile are exported as expected, I
thought it might be a bug concerning the failure to export LD_LIBRARY_PATH.
This is not a big problem and, execpt for firefox issues, I am quite pleased
with Fedora 6.

Hi Robert,

Also it would be interesting if you could grep for LD_LIBRARY_PATH in the other
files in /etc/profile.d and report whether any of them are stomping over the
value rather than appending.

I read every script ending in .sh and didn't see anything for LD_LIBRAY_PATH. I
did add export statements in a script under /etc/profile.d and LD_LIBRARY_PATH
is now correctly exported to user environment.
Previously, when LD_LIBRARY_PATH didn't show I could enter the line commmand
"source /etc/profile" (w/o quotes of course) and the LD_LIBRARY_PATH showed in
the gnome terminal window.

Another possibility is some process we're running through during start up is
setuid.  That would filter out all the LD_ environment variables. 

ah ha!
$ ls -l /usr/bin/ssh-agent
-rwxr-sr-x 1 root nobody 85064 2007-01-16 16:24 /usr/bin/ssh-agent

(this seems sort of familiar to me now, we may have come across this bug before)

So we either need to change how we invoke ssh-agent to use the alternative
syntax or proxy the LD_ environment variables through the other side

(by doing something like exec -l $SHELL "blah blah ssh-agent env
LD_LIBRARY_PATH=$LD_LIBRARY_PATH $command" instead of the exec -l $SHELL "blah
blah ssh-agent $command" that we do now)

Reassigning to the Xsession script owner.

*** This bug has been marked as a duplicate of 164869 ***