Bug 430187

Summary: /usr/local/bin is lost in GNOME
Product: [Fedora] Fedora Reporter: Pete Zaitcev <zaitcev>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-29 04:53:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Pete Zaitcev 2008-01-25 03:10:55 UTC
Description of problem:

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

[zaitcev@niphredil ~]$ echo $PATH

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


How reproducible:

Synchronous 100%

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

PATH is:

Expected results:


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 19:07:13 UTC
Are you still seeing this with current rawhide?

Comment 2 Pete Zaitcev 2008-03-18 21:13:14 UTC
Re-checked now, still the same (gdm-2.21.9-3.fc9).

Comment 3 Ray Strode [halfline] 2008-03-18 21:27:53 UTC
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 22:42:25 UTC
(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 15:01:19 UTC
So this is totally gdm's fault:

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

Will be fixing shortly.

Comment 6 Ray Strode [halfline] 2008-03-19 15:38:51 UTC
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 04:53:25 UTC
Seems to be fixed in rawhide.

Comment 8 Kenneth Topp 2008-04-15 17:28:02 UTC
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 21:36:29 UTC
gdm runs before login, the users login shell runs after login.