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
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
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)

(edit)
Clone Of:
(edit)
Last Closed: 2007-02-14 09:04:45 UTC


Attachments (Terms of Use)
output from ENV command to text file (1.76 KB, text/plain)
2007-02-09 19:51 UTC, Robert Finlon
no flags Details
shopt login_shell > shopt.txt (20 bytes, text/plain)
2007-02-12 20:20 UTC, Robert Finlon
no flags Details
/etc/profile (1.41 KB, application/octet-stream)
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
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 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/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 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
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 17:23:03 UTC
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 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.