GNOME logins dont run .bash_profile in RHEL7

Latest response

Here's the second of my hopefully-simple questions I hope someone can easily answer. Unlike in 6.5, GNOME does not source the ~/.bash_profile when logging on at the GUI. This results in a user's PATH being inconsistent between logging on at the GUI and ssh-ing. I can't seem to find a key in login-screen or anywhere else that I can tell the display manager to source the .bash_profile. (I dont want to set the terminal to do it - .bash_profile has items that should be run once, not once per subshell.)

Anyone know if there is a setting somewhere that makes gdm source the file as it did in 6.5?

I checked on a second system and it IS sourcing the file. Again, anyone know where this feature might be set so that I can check this? Thanks.

Responses

It looks like this issue was fixed recently. When I updated the system that displayed the behavior, the problem went away.

I'm still curious if there was a setting somewhere. If anyone can answer that I'd appreciate it.

Hi Greg,

The ~/.bash_profile file is (should) only be sourced when Bash is started in interactive, login mode. When you're logging in graphically (using GDM or other display manager), the script that launches the session sources the ~/.profile file. So you can use that one.

I just checked on a RHEL7 machine, and the ~/.bash_profile file really isn't sourced by GDM, so it's strange that it'd be 'fixed' as you've added. In any case, should you need it, you can add a command to source any file you want to the /etc/X11/xinit-xinitrc-common file (which is where you can find the command that sources ~/.profile by default).

Hi again Robert -
It took some time to get around to this, but I did a controlled experiement on three systems with the same limited account installed: a RH6.5 system, RH7 (before updates and RH7 (after updates).
On the account on each system, a single directory was prepended to the PATH variable in the ~/.bash_profile. That is the only place that particular directory was placed in the PATH.
What I found was the same as my earlier checks:
* on RH6.5, and examination of the environ file of gnome-session revealed that its PATH had been initialized with the .bash_profile PATH.
* on RH7 before updates, the environ file of the parent of the desktop shell (whose parent had exited), gnome-terminal-server, did not have the extra PATH component, and neither did the desktop shell.
* on RH7 after updates, the environ file of the gnome-terminal-server still did not have the PATH component, but its child, my desktop shell, did.

on RH7, the desktop shell in both cases had a SHLVL greater than 1, so it did not source the .bash_profile itself.

So, whatever the case, the initial RH7 release had this inconsistency about the environment relative the 6.5, but a currently-updated RH7 system is consistent. This is good news for us.

I agree with you that I cant find where in the code this happens (although I do see where the ~/.profile is sourced in the X11 startup code and there are some exec -l's happening), but the X11 startup code is extremely hard to follow - and the process structure after a user has logged in is also hard to follow (maybe the user's control groups would tell me more? - I'm not used to cgroups yet...)