Bug 430187 - /usr/local/bin is lost in GNOME
/usr/local/bin is lost in GNOME
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-24 22:10 EST by Pete Zaitcev
Modified: 2008-04-15 17:36 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-29 00:53:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pete Zaitcev 2008-01-24 22:10:55 EST
Description of problem:

The environment variable PATH has no /usr/local/bin (but has two
/usr/bin):

[zaitcev@niphredil ~]$ echo $PATH
/usr/kerberos/bin:/bin:/usr/bin:/usr/bin

Version-Release number of selected component (if applicable):

setup-2.6.10-1.fc8
gdm-2.21.5-1.fc9
bash-3.2-20.fc9
pam-0.99.8.1-15.fc9

How reproducible:

Synchronous 100%

Steps to Reproduce:
1. Log in into GNOME
2. Launch gnome-terminal
3. Run echo $PATH
  
Actual results:

PATH is:
/usr/kerberos/bin:/bin:/usr/bin:/usr/bin

Expected results:

PATH:
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin

Additional info:

I don't really know what broke, because I did not update Rawhide for
a month due to X issues. The setup RPM was updated, but it seems
benign. Ditto initscripts. So, I think maybe gdm, because gdm
invokes PAM.

Note that logging in on text console, everything is ok.
Comment 1 Ray Strode [halfline] 2008-03-18 15:07:13 EDT
Are you still seeing this with current rawhide?
Comment 2 Pete Zaitcev 2008-03-18 17:13:14 EDT
Re-checked now, still the same (gdm-2.21.9-3.fc9).
Comment 3 Ray Strode [halfline] 2008-03-18 17:27:53 EDT
so gdm run exactly one login shell as part of the login process.  The login
shell will source /etc/profile and ~/.bash_profile

~/.bash_profile by default sources ~/.bashrc

are you frobbing PATH in ~/.bash_profile or ~/.bashrc ?
Comment 4 Pete Zaitcev 2008-03-18 18:42:25 EDT
(In reply to comment #3)
> are you frobbing PATH in ~/.bash_profile or ~/.bashrc ?

Of course not, jeez! I wouldn't bother you if this was something
like that. But I checked just in case right now, and nope.
I rechecked /etc/profile and /etc/profile.d/* too.

Look, the problem is two fold:
 1) I didn't do anything, just ran "yum update" one day and it started.
 2) I have no clue what component is actually at fault, but everything
    works as before on Linux console. So I'm using gdm as kind of a
    bracket for "things which parent my processes in GNOME session".
    Maybe it's the gnome-session, not gdm. How do I find out?

Unfortunately, gnome-terminal daemonizes itself or else its parent
has exited, so I cannot follow the process tree to the offender.
Comment 5 Ray Strode [halfline] 2008-03-19 11:01:19 EDT
So this is totally gdm's fault:

        gdm_session_direct_set_environment_variable (session,
                                                     "PATH",
                                                     "/bin:/usr/bin:" BINDIR);

Will be fixing shortly.
Comment 6 Ray Strode [halfline] 2008-03-19 11:38:51 EDT
Should be fixed in gdm-2.21.10-0.2008.03.18.2.fc9 which won't make the beta.
Comment 7 Matthias Clasen 2008-03-29 00:53:25 EDT
Seems to be fixed in rawhide.
Comment 8 Kenneth Topp 2008-04-15 13:28:02 EDT
I don't think this is the correct fix.

gdm is  setting the PATH since there is no path set at all.

The PATH should have been caried through from the users login shell, but
something is wiping it out.
Comment 9 Ray Strode [halfline] 2008-04-15 17:36:29 EDT
gdm runs before login, the users login shell runs after login.

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