Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 228019 - BASH not exporting all /etc/profile variables.
Summary: BASH not exporting all /etc/profile variables.
Status: CLOSED DUPLICATE of bug 164869
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-09 16:13 UTC by Robert Finlon
Modified: 2018-04-11 19:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-02-14 09:04:45 UTC

Attachments (Terms of Use)
output from ENV command to text file (deleted)
2007-02-09 19:51 UTC, Robert Finlon
no flags Details
shopt login_shell > shopt.txt (deleted)
2007-02-12 20:20 UTC, Robert Finlon
no flags Details
/etc/profile (deleted)
2007-02-13 17:23 UTC, Robert Finlon
no flags Details

Description Robert Finlon 2007-02-09 16:13:19 UTC
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 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.

Comment 1 Tim Waugh 2007-02-09 16:22:27 UTC
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..

Comment 2 Robert Finlon 2007-02-09 16:34:41 UTC
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.

Comment 3 Tim Waugh 2007-02-09 17:20:07 UTC
So gnome-terminal?

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

Comment 4 Robert Finlon 2007-02-09 19:51:51 UTC
Created attachment 147798 [details]
output from ENV command to text file

 file created via ENV > env.txt

Comment 5 Tim Waugh 2007-02-12 19:00:46 UTC
Sorry, I need to see the output of 'shopt login_shell'.

Comment 6 Robert Finlon 2007-02-12 20:20:42 UTC
Created attachment 147936 [details]
shopt login_shell > shopt.txt

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

Comment 7 Michael Kearey 2007-02-13 06:57:16 UTC
Robert, I have attempted to replicate the problem you have. I added the
following file called /etc/profile.d/ 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?

Comment 8 Tim Waugh 2007-02-13 09:18:51 UTC
> 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.

Comment 9 Robert Finlon 2007-02-13 14:52:43 UTC
I am currently setting variables in the /etc/profile but will change my setup to
use profile.d as recommended. 

Comment 10 Ray Strode [halfline] 2007-02-13 15:53:15 UTC
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[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?

Comment 11 Robert Finlon 2007-02-13 17:23:03 UTC
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.

Comment 12 Ray Strode [halfline] 2007-02-13 19:13:17 UTC
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.

Comment 13 Robert Finlon 2007-02-13 19:27:39 UTC
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.

Comment 14 Ray Strode [halfline] 2007-02-13 20:17:31 UTC
Another possibility is some process we're running through during start up is
setuid.  That would filter out all the LD_ environment variables. 

Comment 15 Ray Strode [halfline] 2007-02-13 20:21:15 UTC
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)

Comment 16 Ray Strode [halfline] 2007-02-13 20:24:55 UTC
Reassigning to the Xsession script owner.

Comment 17 Matěj Cepl 2007-02-14 09:04:45 UTC

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

Note You need to log in before you can comment on or make changes to this bug.