Red Hat Bugzilla – Bug 228019
BASH not exporting all /etc/profile variables.
Last modified: 2018-04-11 15:08:08 EDT
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.
create variable in /etc/profile
Steps to Reproduce:
2.logout/login or reboot
3.run echo $LD_LIBRARY_PATH
no LD_LIBRARY_PATH variable is shown.
The LD_LIBRARY_PATH variable should be shown.
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.
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 :
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
There have been bugs in the past with bash and ksh where they didn't work quite
right if argv 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]
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.
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.
$ 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 ***