Description of problem: LD_LIBRARY_PATH not exported to user environment Version-Release number of selected component (if applicable): 3.1.7 (for 64-bit. How reproducible: create variable in /etc/profile Steps to Reproduce: 1.edit /etc/profile 2.logout/login or reboot 3.run echo $LD_LIBRARY_PATH Actual results: no LD_LIBRARY_PATH variable is shown. Expected results: The LD_LIBRARY_PATH variable should be shown. Additional info: Same problem with Fedora 6 for 32-bit.
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 ***