Bug 177258 - xinit Xsession script sometimes fails to execute login shells
xinit Xsession script sometimes fails to execute login shells
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Mike McLean
: 173438 173936 174653 177130 (view as bug list)
Depends On:
Blocks: FC5Target
  Show dependency treegraph
Reported: 2006-01-08 07:20 EST by Nicolas Mailhot
Modified: 2007-11-30 17:11 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-27 09:59:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2006-01-08 07:20:54 EST
Description of problem:

launch gnome-terminal
$ cvs co foo
cvs checkout: No CVSROOT specified!  Please use the `-d' option
cvs [checkout aborted]: or set the CVSROOT environment variable

$ . ~/.bash_profile
$ cvs co foo
-> works

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

Comment 1 Robert Scheck 2006-01-08 10:50:04 EST
I can't confirm this after a SSH login:

robert@tux:~ > echo $PATH
robert@tux:~ > 

robert@tux:~ > grep PATH .bash*
.bash_profile:export PATH
robert@tux:~ >
Comment 2 Nicolas Mailhot 2006-01-08 11:38:04 EST
Actually it works when logged on the CLI, not when opening a gnome-term on the GUI
Comment 3 Tim Waugh 2006-01-09 04:07:26 EST
Please clarify: which situation does bash *not* read .bash_profile in, when it
ought to?

Only login shells should read .bash_profile, and a gnome-terminal shell is not a
login shell unless you enabled the check-button in the preferences.
Comment 4 Nicolas Mailhot 2006-01-09 04:48:06 EST
well, gnome-term is not really useful if PATH or other shell env vars are not
initialised properly. The default .bash* files seem to say this initialising
belong in  .bash_profile.

I guess what you mean is the behaviour change problem is a gnome-term problem
not a bash one. Please confirm so I can reassign the boog.
Comment 5 Tim Waugh 2006-01-09 05:05:10 EST
As far as I can tell, everything is working correctly: gnome-terminal has an
option for whether the shell should be a login shell, and defaults to off; bash
reads .bash_profile when invoked with -l (for example).

Is the observed symptom a *change* in behaviour?  The summary seems to suggest
so.  If so, when was the behaviour any different?
Comment 6 Nicolas Mailhot 2006-01-09 05:40:39 EST
It's a change in behaviour. It's a new account, so maybe I had manually checked
the gnome-term option before

I would argue in this case the default is wrong as it's not "just working"

But that's a gnome problem not a bash one
Comment 7 Sammy 2006-01-09 10:35:16 EST
To add my 2cents worth....the PATH is picked up from /etc/bashrc in konsole
under KDE. However, startkde sh script is not picking up the correct PATH
from bashrc or profile but assigns a default path instead. I have applications
that have their bash shell windows (e.g. IDE's) that do not have access to my
path, which contains additional directories.

If the behavior is changed, what way? Do we need to add a flag to #!/bin/sh
to execute profiles?

I field a bug separately with KDE for this, since it used to work before.
Comment 8 Ray Strode [halfline] 2006-01-09 21:50:44 EST
Hi guys,

this was a result of a gdm upgrade, where we switched Xsession files from Fedora
specific to upstream.  The Fedora Xsession file executes things in a login shell
which causes the profiles to execute on login.  The upstream gdm Xsession file
just sourced ~/.profile but didn't execute a login shell.

I switched back to the Fedora Xsession file today.
Comment 9 Ray Strode [halfline] 2006-01-09 21:55:21 EST
*** Bug 174653 has been marked as a duplicate of this bug. ***
Comment 10 Ray Strode [halfline] 2006-01-09 21:57:08 EST
*** Bug 173438 has been marked as a duplicate of this bug. ***
Comment 11 Sammy 2006-01-10 10:20:51 EST
This did not work for kdm. The startup sequence must be different. If I put
the PATH into /etc/profile.d/lang.sh file then is it picked up correctly.
Comment 12 Ray Strode [halfline] 2006-01-10 10:53:47 EST
Hi Sammy,

Can you file a new bug against kdebase explaining your problem?

Comment 13 Ray Strode [halfline] 2006-01-10 11:03:47 EST
*** Bug 173936 has been marked as a duplicate of this bug. ***
Comment 14 Sammy 2006-01-10 11:08:11 EST
I have filed a bug against kdebase already before this bug but did not
hear anything yet.
Comment 15 Ray Strode [halfline] 2006-01-10 11:15:40 EST
Hi Sammy,

Great thanks! Can you mention the bug number of that report on this report?
Comment 16 Sammy 2006-01-10 11:24:04 EST
Yes, it is:


Comment 17 Kenneth Topp 2006-01-12 10:17:18 EST
now we are dealing with a bash bug?  With the full path (ie: $SHELL) it doesn't
seem to load the profile..

toppk@one:~ (0)$ exec -l /bin/bash  -c /bin/bash
toppk@one:~ (0)$ exec -l bash  -c /bin/bash
Loading .bash_profile
toppk@one:~ (0)$ 
Comment 18 Ray Strode [halfline] 2006-01-13 11:48:41 EST
Yup, there's a bash bug there.  It looks like a few other shells get it wrong,
too, though.  We probably need to come up with a workaround in xorg-x11-xinit.
Reopening and assigning to xorg-x11-xinit.
Comment 19 Ray Strode [halfline] 2006-01-13 12:06:36 EST
So Tim fixed this in bash-3.1-5 to work again (should be available in tomorrow's
rawhide).  Other shells that are broken still need to be fixed, but this should
make things better for most users.
Comment 20 Sammy 2006-01-13 14:39:58 EST
Yes, this is fixed (I downloaded and built 3.1-5) BUT I am having yet
another problem:

When logged in as KDE user (should not matter), I do a ctrl+alt+F1
to switch to a text console and login to my account. Unfortunately,
login hangs until I hit ctrl-c, which then gives me the prompt:


Yes, starts with "-". Can anyone confirm this?
Comment 21 Ray Strode [halfline] 2006-01-13 16:58:26 EST

sounds like a bug in the fix.  Can you file a new bug against bash and report
the bug number here?
Comment 22 Ray Strode [halfline] 2006-01-13 17:40:54 EST
*** Bug 177130 has been marked as a duplicate of this bug. ***
Comment 23 Tim Waugh 2006-01-17 04:52:26 EST
Sammy: please file a separate bug report and put in your text from comment #20.
Comment 24 Michal Jaegermann 2006-02-22 23:32:47 EST
AFAICS after recent updates to FC5t3 the problem is back.  If this is really
a responsibility of bash then this is with bash-3.1-6.2 package.
Comment 25 Tim Waugh 2006-02-23 04:25:21 EST
[root@cyberelk /]# shopt | grep login
login_shell     off
[root@cyberelk /]# sh -c 'exec -l /bin/bash -c shopt' | grep login
login_shell     on
[root@cyberelk /]# rpm -q bash

So bash is still correctly becoming a login shell when it sees '-/bin/bash' in

Do you see different results from that command?
Comment 26 Michal Jaegermann 2006-02-23 12:20:10 EST
Results, which I am seeing, from commands in comment #25 are exactly the same.
Still on a desktop ~/.bash_profile is not processed with effects like in the
original report.

'gnome-terminal' does not have '--login' option anymore and it hardly looks
like the right place to be responsible for that. 'xterm -ls' will run
~/.bash_profile but this is clearly not the answer.  What is more
'gnome-terminal' opened from inside 'xterm' does not inherit its environment.
Is this the real bug?
Comment 27 Tim Waugh 2006-02-23 12:29:44 EST
I don't know how this works beyond the shell.

rstrode/mharris: is this a GNOME problem, or an Xsession problem?
Comment 28 Sammy 2006-02-23 14:55:13 EST
Check to see if /etc/X11/xdm/Xsession is the generic X11 one or the longer
RedHat one that refers to various sessions. It is probably the generic one.
Gnome/KDE have to point to another Xsession in xinit (in KDE), if
you look under /etc/kde/kdm logical links, and /usr/share/config/kdm link.
If any of these is broken/altered than Gnome/KDE will not use the right
Xsession that executes the login shell. This happened to me at some point
when xdm package was updated but then it got fixed by the maintainers of
Desktops, I think!
Comment 29 Michal Jaegermann 2006-02-23 15:51:38 EST
> Check to see if /etc/X11/xdm/Xsession is the generic X11

It looks like a "generic" one.  It is from xorg-x11-xdm-1.0.1-1.2
and 'rpm -V xorg-x11-xdm' does not have anything to report.

> If any of these is broken/altered than Gnome/KDE will not use the right
> Xsession that executes the login shell.

It seems that there is a problem here.  How is /etc/X11/xdm/Xsession to
know what is my login shell?  It happens to be bash at this moment but it
does not have to be.
Comment 30 Sammy 2006-02-23 16:19:32 EST
To quickly see if this is the problem find the other Xsession e.g.
from /etc/X11/xinit directory and copy it to /etc/X11/xdm directory
(save Xsession there first). Restart X and possible gdm/kdm again
and see if it all works.
Comment 31 Ray Strode [halfline] 2006-02-23 19:42:12 EST
what does cat /etc/gdm/custom.conf /usr/share/gdm/defaults.conf | grep -i xsession

Comment 32 Mike A. Harris 2006-02-24 06:57:36 EST
(In reply to comment #27)
> I don't know how this works beyond the shell.
> rstrode/mharris: is this a GNOME problem, or an Xsession problem?

Comment #8 suggests it is a gdm bug.  To the best of my knowledge, the
FC5 files are identical to the FC4 and earlier ones modulo bugfixes and
whatnot.  I don't believe anything has changed in the xdm/xinit scripts
or configs between FC4 and FC5 which would cause this type of problem.

Someone might want to strace through the gdm/X startup perhaps to see
what is happening.

Comment 33 Ray Strode [halfline] 2006-02-24 12:09:33 EST

That's not exactly true.  I believe you used to install the system Xsession in
/etc/X11/xdm/Xsession and now install it in /etc/X11/xinit/Xsession. 
/etc/X11/xdm/Xsession now contains an upstream Xsession file.  This change
happened when we went modular.

GDM was updated to point to the new Xsession file, but it's conceivable the old
file is lingering in people's configurations.

I'd recommond deleting /etc/X11/xdm/Xsession in the xdm package and symlink it
to the system Xsession file.
Comment 34 Michal Jaegermann 2006-02-24 12:59:27 EST
About comment #30.  Replacing /etc/X11/xdm/Xsession with the current
/etc/X11/xinit/Xsession does not help.  They are obviously different but
it is not clear which one is actually used and anyway I do not see there
a code which would process user shell startup.

If I will patch /etc/gdm/Xsession the following way

--- /etc/gdm/Xsession.orig	2006-02-19 00:22:51.000000000 -0700
+++ /etc/gdm/Xsession	2006-02-24 10:53:40.000000000 -0700
@@ -36,7 +36,8 @@ echo "$0: Beginning session setup..."
 # First read /etc/profile and .profile
 test -f /etc/profile && . /etc/profile
-test -f "$HOME/.profile" && . "$HOME/.profile"
+test -f "$HOME/.bash_profile" && . "$HOME/.bash_profile" || \
+{ test -f "$HOME/.profile" && . "$HOME/.profile"; }
 # Second read /etc/xprofile and .xprofile for X specific setup
 test -f /etc/xprofile && . /etc/xprofile
 test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

then my ~/.bash_profile is indeed processed.  I did changes of that sort
while waiting for the previous incarnation of this bug to be fixed but
I thought that this is not longer required.  Apparently it still is.
I am not sure what happens if somebody is using, say, kdm instead.
This is with gdm-
Comment 35 Ray Strode [halfline] 2006-02-24 13:42:27 EST
Hi Michal,

What if you replace /etc/gdm/Xsession with the current /etc/X11/xinit/Xsession ?

We aren't supposed to be shipping /etc/gdm/Xsession. I'll fix it.
Comment 36 Sammy 2006-02-24 13:45:09 EST
Don't you have lines like:

exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session"

in your /etc/X11/xinit/Xsession file? The whole thing is working
for KDE which used these files so the problem cannot be bash. Are
there other gnome users having the same problem?
Comment 37 Michal Jaegermann 2006-02-24 14:13:16 EST
Well, yes, replacing /etc/gdm/Xsession with /etc/X11/xinit/Xsession looks
like it works - regardless of what is in /etc/X11/xdm/Xsession.  Too many
of these Xsession files are floating around. :-)

Yes, there is a line

       exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session"

in /etc/X11/xinit/Xsession but clearly this is not what is really executed
in a default setup.

Just removing /etc/gdm/Xsession in the current situation is not the answer.
There is "BaseXsession=/etc/gdm/Xsession" reference in /etc/gdm/custom.conf.
One could change that, of course to point to /etc/X11/xinit/Xsession and
then shell startup files are processed, not that surprisingly, too.

I am not sure what to do with /etc/X11/xdm/Xsession.  It appears that this
better be a link to /etc/X11/xinit/Xsession as well.
Comment 38 Ray Strode [halfline] 2006-02-24 16:03:59 EST

In the default setup BaseXsession=/etc/X11/xinit/Xsession.  Have a look at

The gdm package was *supposed* to delete its Xsession file and just create a
symlink to the system one in the off chance someone whos been following rawhide
over the last few months had BaseXsession=/etc/gdm/Xsession in their config
file.  It did this for a few releases, but I broke it when I moved gdm from
/etc/X11/gdm to /etc/gdm (I forgot to change /etc/X11/gdm to /etc/gdm in a few
places in the spec file).

Should be fixed in tomorrow's rawhide, but Mike should still fix xdm though.
Comment 39 Michal Jaegermann 2006-02-24 17:21:06 EST
> In the default setup BaseXsession=/etc/X11/xinit/Xsession.

Good to know but something in recent series of updates rewrote
/etc/gdm/custom.conf; or at least it changed timestamp there.  I was not
that pleased as no original was left and I could not check what was changed.
What is more, I am pretty sure that before these updates /etc/gdm/Xsession
was not there.  If not that detail that it showed back I could have catch
up what is the real culprit sooner.

BTW, are two copies of this file in /usr/share/gdm/ really needed?
defaults.conf and factory-defaults.conf do not differ.
Comment 40 Havoc Pennington 2006-02-25 12:19:30 EST
This is fixed for me now in gdm, but I manually changed the
/etc/gdm/Xsession symlink to "/etc/X11/xinit/Xsession" instead of
"../xinit/Xsession" (I guess RPM doesn't change symlinks?)

Comment 41 Michal Jaegermann 2006-02-25 13:32:33 EST
> This is fixed for me now in gdm ...

# rpm -q gdm
# rpm -qlv gdm | grep Xsession
 ......   17 Feb 24 12:15 /etc/gdm/Xsession -> ../xinit/Xsession

This is a wrong link.  It should be to ../X11/xinit/Xsession or you are
ending up with a dead link in /etc/gdm if Xsession was not there.

I just edited 'BaseXsession' in custom.conf to point to the right one and
which seems like a more reliable way.  Postintall edits this file anyway.
At least this is done:

if [ $1 -ge 2 ]; then
   sed -i -e 's@/etc/X11/gdm@/etc/gdm@g' /etc/gdm/custom.conf

while this _really_ should be

if [ $1 -ge 2 ] && grep -q /etc/X11/gdm /etc/gdm/custom.conf ; then
   sed -i -e 's@/etc/X11/gdm@/etc/gdm@g' /etc/gdm/custom.conf

to avoid spurious edits and time-stamp changes when none is needed.

Other edits are weird too.  Instead of one sed call with multiple actions
there is there a huge pile of separate sed calls each one rewriting the same
file in place and considerably raising a chance that something will go wrong.

Admitedly this happens only if there is /etc/X11/gdm/gdm.conf to migrate
but then why not simply

 sed "all actions here" /etc/X11/gdm/gdm.conf > /etc/gdm/custom.conf

And after all of that we clobber results with a copy of
/usr/share/gdm/config/gdm.conf-custom if we find one.  Hm ....

> I guess RPM doesn't change symlinks?

Packages are unpacked with cpio and cpio will not clobber an existing file
with a symlink; but it is possible in %pre script to move, if it exists,
/etc/gdm/Xsession to a backup file and then a symlink will show up.  Make
sure that it is to something which does exist.
Comment 42 Ray Strode [halfline] 2006-02-25 16:34:37 EST
Hey guys, 

I fixed the broken symlink this morning.  It should be moved into rawhide
sometime this weekend.

Could you file separate bugs about the other spec file clean ups?

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