Bug 228019 - BASH not exporting all /etc/profile variables.
BASH not exporting all /etc/profile variables.
Status: CLOSED DUPLICATE of bug 164869
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-09 11:13 EST by Robert Finlon
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-14 04:04:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output from ENV command to text file (1.76 KB, text/plain)
2007-02-09 14:51 EST, Robert Finlon
no flags Details
shopt login_shell > shopt.txt (20 bytes, text/plain)
2007-02-12 15:20 EST, Robert Finlon
no flags Details
/etc/profile (1.41 KB, application/octet-stream)
2007-02-13 12:23 EST, Robert Finlon
no flags Details

  None (edit)
Description Robert Finlon 2007-02-09 11:13:19 EST
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.
Comment 1 Tim Waugh 2007-02-09 11:22:27 EST
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 11:34:41 EST
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 12:20:07 EST
So gnome-terminal?

And is it configured as a login terminal?  What does 'shopt login_shell' say?
Comment 4 Robert Finlon 2007-02-09 14:51:51 EST
Created attachment 147798 [details]
output from ENV command to text file

 file created via ENV > env.txt
Comment 5 Tim Waugh 2007-02-12 14:00:46 EST
Sorry, I need to see the output of 'shopt login_shell'.
Comment 6 Robert Finlon 2007-02-12 15:20:42 EST
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 01:57:16 EST
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?


Comment 8 Tim Waugh 2007-02-13 04:18:51 EST
> 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 09:52:43 EST
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 10:53:15 EST
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?

Comment 11 Robert Finlon 2007-02-13 12:23:03 EST
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.
Comment 12 Ray Strode [halfline] 2007-02-13 14:13:17 EST
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 14:27:39 EST
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 15:17:31 EST
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 15:21:15 EST
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 15:24:55 EST
Reassigning to the Xsession script owner.
Comment 17 Matěj Cepl 2007-02-14 04:04:45 EST

*** 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.