Bug 73062 - gdm runs Xsession in a non-login shell
gdm runs Xsession in a non-login shell
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: gdm (Show other bugs)
null
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Jay Turner
:
Depends On: 66486
Blocks: 67217
  Show dependency treegraph
 
Reported: 2002-08-30 06:22 EDT by Jens Petersen
Modified: 2015-01-07 19:00 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-09-05 21:19:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch to make xinput source i18n config files for XIM, etc (494 bytes, patch)
2002-09-04 00:31 EDT, Jens Petersen
no flags Details | Diff

  None (edit)
Description Jens Petersen 2002-08-30 06:22:11 EDT
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):
xinitrc-3.27-1

How Reproducible:
every time

Steps to Reproduce:
1. put XIM=skkinput in "~/.bashrc"
2. start a new gdm session
3. printenv XIM

Actual Results:
XIM is not set.

Expected Results:
XIM should have been set.

Additional Information:
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.
Comment 1 Mike A. Harris 2002-09-01 06:16:29 EDT
gdm is configurable aparently on wether or not a login shell is used
or not.

I do not recall making any changes to xinitrc package that would
cause this to happen since 7.3.  Has anyone else changed anything?
Comment 2 Jens Petersen 2002-09-02 05:05:44 EDT
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.
Comment 3 Havoc Pennington 2002-09-02 17:31:30 EDT
.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
.bash_profile.
Comment 4 Bill Nottingham 2002-09-03 00:19:52 EDT
Still, this is odd that it worked in 7.3 and didn't now... people will probably
expect their configs to work the same.
Comment 5 Havoc Pennington 2002-09-03 01:07:12 EDT
well, what makes a shell interactive? isatty(stdin)?
Comment 6 Jens Petersen 2002-09-03 10:49:40 EDT
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.]
Comment 7 Jens Petersen 2002-09-03 11:15:32 EDT
This bug looks like

http://bugzilla.gnome.org/show_bug.cgi?id=77335
Comment 8 Jens Petersen 2002-09-03 11:21:20 EDT
(Reassigning to gdm, since it looks closer to the problem.)
Comment 9 Havoc Pennington 2002-09-03 11:28:13 EDT
.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
http://bugzilla.gnome.org/show_bug.cgi?id=77335
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.
Comment 10 Havoc Pennington 2002-09-03 11:30:45 EDT
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
terminal.
Comment 11 Jens Petersen 2002-09-03 12:03:22 EDT
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.
Comment 12 George Lebl 2002-09-03 12:08:38 EDT
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
.xprofile.

So in the future you would put such stuff in ~/.xprofile or /etc/xprofile
Comment 13 Havoc Pennington 2002-09-03 12:48:21 EDT
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
/etc/profile.d?

George - ah, but we haX0rd our gdm to not run the shell as a login shell. ;-)
Comment 14 Mike A. Harris 2002-09-03 18:37:06 EDT
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.
Comment 15 Jens Petersen 2002-09-03 21:22:47 EDT
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?
Comment 16 Havoc Pennington 2002-09-03 21:47:36 EDT
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.
Comment 17 Jens Petersen 2002-09-03 21:54:58 EDT
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.

gdm-2.4.0.7-dbllogin-66486.patch

[Fixing summary to be more precise]
Comment 18 George Lebl 2002-09-03 23:47:42 EDT
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
  ...
fi

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).
Comment 19 Jens Petersen 2002-09-04 00:16:00 EDT
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
"/etc/profile.d/lang.sh").

Does it look ok, Mike?
Comment 20 Jens Petersen 2002-09-04 00:20:53 EDT
(Thought I had already added Mike to the CC list...)
Comment 21 Jens Petersen 2002-09-04 00:31:25 EDT
Created attachment 74826 [details]
patch to make xinput source i18n config files for XIM, etc
Comment 22 Jens Petersen 2002-09-04 01:40:24 EDT
Errm, that patch doesn't work for startx sessions unfortunately.
Back to the drawing board...
Comment 23 Jens Petersen 2002-09-04 02:42:14 EDT
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.
Comment 24 Jens Petersen 2002-09-04 03:44:45 EDT
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...
Comment 25 Havoc Pennington 2002-09-04 09:15:41 EDT
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
profile.d?
Comment 26 Jens Petersen 2002-09-05 03:38:33 EDT
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.
Comment 27 Owen Taylor 2002-09-05 12:34:37 EDT
The minimally non-intruisive thing to me seems to be to add 

if [ -f /etc/profile.d/lang.sh ] ; then 
  . /etc/profile.d/lang.sh
fi

to /etc/X11/xinit/xinitrc.d/xinput

This makes:

Adding:

 LANG=ja_JP
 XIM=skkinput

Work for me for both startx and gdm. I guess it makes:

 XIM=skkinput startx

*Not* work, but I don't think we should care about that.
Comment 28 Owen Taylor 2002-09-05 14:17:50 EDT
xinitrc-3.29 adds the sourceing of lang.sh to xinput. This (in my testing)
allows setting the input method by adding 
 
 XIM=skkinput

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
wakes up)
Comment 29 Paul Gampe 2002-09-05 20:49:35 EDT
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. 
 
ja_JP.eucJP 
ko_KR.eucKR 
zh_TW.Big5 
zh_CN.GB18030 
Comment 30 Owen Taylor 2002-09-05 21:19:29 EDT
Could you file this separately, so we can close this bug? It's not
related. 

(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.)
Comment 31 Jens Petersen 2002-09-05 23:29:54 EDT
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.

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