Red Hat Bugzilla – Bug 73062
gdm runs Xsession in a non-login shell
Last modified: 2015-01-07 19:00:00 EST
Description of Problem:
When a gdm session is started, the bash config files are not being sourced.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. put XIM=skkinput in "~/.bashrc"
2. start a new gdm session
3. printenv XIM
XIM is not set.
XIM should have been set.
This is a regression relative to RHL 7.3.
With zsh as one's login shell, this problem does not occur.
This bug means that in particular it is next to impossible for bash
users to pass XIM say to /etc/X11/xinit/xinitrc.d/xinput to select
an alternative IM or pass commandline options to it.
gdm is configurable aparently on wether or not a login shell is used
I do not recall making any changes to xinitrc package that would
cause this to happen since 7.3. Has anyone else changed anything?
Is the configuration done at build time? I don't see any relevant
options in gdm.conf or anywhere in /etc/X11/gdm in fact.
Of course the version of gdm changed changed since 7.3.
Well, zsh works fine, but bash doesn't.
.bashrc has nothing to do with login shell or not, it has to do with whether the
shell is interactive. I'm not sure the shell run on login counts as interactive,
it doesn't seem like it would; to run stuff on login you would want to use
Still, this is odd that it worked in 7.3 and didn't now... people will probably
expect their configs to work the same.
well, what makes a shell interactive? isatty(stdin)?
Isn't it more to do with login shell vs non-login shell?
For a non-interative shell "bash --login" should read
".bash_profile", otherwise by default it doesn't read anything
(unless BASH_ENV is set). I suspect the user's shell isn't being
called as a login shell somewhere (gdm? gnome-session?)
[zsh by default always sources .zshenv, explaining why it is not
affected by this problem so badly.]
This bug looks like
(Reassigning to gdm, since it looks closer to the problem.)
.bashrc has nothing to do with login shell or not. We do the login shell stuff
in the Xsession script not in gdm, so should be getting a login shell for all
users including tcsh users. So basically
should not impact our setup.
.bashrc is keyed purely off of interactivity... the login shell _isn't_
interactive, so I'm awfully inclined to NOTABUG this and say 7.3 was busted.
From the bash manual:
What is an Interactive Shell?
An interactive shell is one started without non-option arguments,
unless `-s' is specified, without specifiying the `-c' option, and
whose input and output are both connected to terminals (as determined
by `isatty(3)'), or one started with the `-i' option.
An interactive shell generally reads from and writes to a user's
I am in full agreement that the shell is not interactive.
What prompted me to file this bug is that it currently doesn't seem
possible to pass environment variables to /etc/X11/xinit/xinitrc.d/*
in a gdm session. In particular this means that Japanese users
won't be able to use skkinput in gdm session instead of kinput2
(by setting "XIM=skkinput" in their .bashrc file say.
So is this a xinitrc package bug after all? It looks like
the xinitrc.d/ files should really be sourced after Xsession exec's
the login shell.
I'm also in full agreement about the .bashrc, though havoc got one thing wrong,
gdm DOES run a login shell session and in it it executes the Xsession script so
currently /etc/profile is run twice. But that's irrelevant since I'm planning
(and the kdm guy is also planning) to change the way this works
1) gdm/kdm will neither run a login shell themselves
2) the standard Xsession script will not be run in login mode bash
3) the standard Xsession will source /etc/profile, .profile, /etc/xprofile and
So in the future you would put such stuff in ~/.xprofile or /etc/xprofile
Jens - I'm not sure how /etc/X11/xinit/xinitrc.d/ works or what it's supposed to
do, so I'm not sure I can answer that question. Can't you put things in
George - ah, but we haX0rd our gdm to not run the shell as a login shell. ;-)
Good point Havoc. I totally missed the interactive/non-interactive
thing. Indeed, .bashrc should only be sourced for interactive shells,
of which a gdm login isn't. This is documented on the bash manpage.
I think we can now close this NOTABUG. Hacking it to fit the requested
behaviour would be bad IMHO.
hp> ah, but we haX0rd our gdm to not run the shell as a login shell. ;-)
Isn't this the cause of the problem then?
No, the Xsession script already does a login shell. We removed it from gdm so
you'd only read .profile and /etc/profile.d one time.
Yes, but I think the fix to bug 66486 would have been better made in
Xsession, than in slave.c. That would fix this problem afaict.
[Fixing summary to be more precise]
Well actually redhat solved it more correctly then I did. But the most correct
would not be using the -login, but some sort of behaviour as I outiled above
(which gdm will use, well will ship Xsession script that will do that, or better
yet this will be a common small package between kdm/gdm). I didn't want to do
such a change within the current release of gdm just in case someone is
depending on the current gdm behaviour.
In any case to solve your current problem, if you want something done only in a
gdm session, you can use the GDMSESSION env var. So you'd still add it to
profile but surround it by something like:
if [ -n "$GDMSESSION" ]; then
or some such. GDMSESSION will always be set to the name of the session picked
by the user (in the future it may be a full path of a script to execute, but
future setup will be saner anyway).
Another workaround is to have the xinput script read "/etc/sysconfig/i18n"
and "~/.i18n", that would solve the problem (and should also already work
in RHL 7.3). Attaching a patch to that effect (new lines just copied from
Does it look ok, Mike?
(Thought I had already added Mike to the CC list...)
Created attachment 74826 [details]
patch to make xinput source i18n config files for XIM, etc
Errm, that patch doesn't work for startx sessions unfortunately.
Back to the drawing board...
Well, actually if we check that XIM isn't defined before
sourcing the i18n config files, I think the behaviour wrt XIM
is as good as in RHL 7.3.
Having the i18n config files sourced appropriately in xinput seems to
involve too many assumptions.
It still seems to me that the only right way to fix this, is to revert the
login shell patch on slave.c in gdm, but anyway...
Jens, you aren't explaining rationale for what you're saying, so it is
hard to know why you are reaching the conclusions you are.
Here is the story:
- all user logins should end up reading /etc/profile.d or /etc/profile.
for a console login this happens when you first log in, for gdm
it happens in Xsession
- if you want all user logins to get a particular env variable, you
would normally put it in /etc/profile.d
So what is special/different about XIM? When do you use xinitrc.d instead of
I guess xinitrc.d has been used until now, because its scripts are only
to be run when starting an X session and at no other time. [I guess they
are the equivalent of the /etc/xprofile that George mentioned.]
In 7.3 and earlier I believe, gdm ran Xsession from a login shell and so
the users' env was present when xinitrc.d/* were sourced by Xsession.
In particular this meant that users could choose their own XIM client by
setting XIM or XIM_PROGRAM in their shell rc file. This is not possible now.
The only other solution I see is moving the sourcing of xinitrc.d/* out of
Xsession and into say gnome-session, and whatever the KDE equivalent is,
or a wrapper shell of those.
In the longer term we are probably going to do all this completely
differently anyway, so it is just a problem now really.
The minimally non-intruisive thing to me seems to be to add
if [ -f /etc/profile.d/lang.sh ] ; then
Work for me for both startx and gdm. I guess it makes:
*Not* work, but I don't think we should care about that.
xinitrc-3.29 adds the sourceing of lang.sh to xinput. This (in my testing)
allows setting the input method by adding
into ~/i18n. While it's unfortunate that the previous method of setting it
putting the setting into ~/.bashrc doesn't work, I think the new method
also makes sense (that's where you configure your language, after all),
and any other change would be far too intrusive at this point.
(Putting this bug into the MODIFIED state for Jens to confirm when he
When GDM_LANG is set it does include the default codeset. So for example if
you select simplified chinese GDM_LANG is set to zh_CN, not the normal LANG
value of zh_CN.GB18030.
At least chinput the Simplified Chinese input method is depandant on knowing
what the locale codeset is, so it fails to start. We have never not specified
the codeset in the LANG variable, so full impact is unknown.
We can either get gdm to include the codeset when it sets GDM_LANG or revert
this patch. I think getting gdm to include codeset is best.
Could you file this separately, so we can close this bug? It's not
(I really think that if chinput has a bug where it is looking at
the string value of the locale rather than the locale name,
it should be fixed.)
Confirmed fixed in xinitrc-3.29-1. Thank you.
FWIW I also agree that using i18n makes at least as much sense
as bashrc. i18n also works in RHL 7.3. Well, this is basically
the change that was discussed above yesterday.