Red Hat Bugzilla – Bug 32408
Logging in via (x|g|k)dm does not source /etc/profile
Last modified: 2007-04-18 12:32:16 EDT
When a user logs in via gdm, xdm, kdm or somesuch display manager, the user's shell is not started as a login shell, which implies that /etc/profile and ~/.profile (or ~/.bash_profile or whichever file the shell uses for that purpose) is not sourced. In turn this introduces problems because environment variables are not properly intitialized at login time. /etc/X11/xdm/Xsession should not do exec gnome-session but LoginExec () { exec - "$SHELL" <<ENDDOC $* ENDDOC } LoginExec exec gnome-session (the `exec -' might need to be turned into `exec -l' for bash-2.0).
This is not a bug. If you're using xterm, or similar, if you want it to start a login shell, read the manual pages for it, and add the parameter to force a login shell. This will source all the files necessary. This is not a bug. For xterm, I believe it is "xterm -ls".
I'm quite aware of the `xterm -ls' thingy, thank you, but I'm not talking about xterm here. I'm talking about setting up the environment that will influence the behavior of *all* the applications the user will use, including those started from a menu or a application-dock or a control-panel or whatever you call it these days. No interactive shell in sight. Things like MANPATH, PATH, LANG, CVSROOT, ... The standard way to do it (for all but XDM logins) is to set it up in /etc/profile (for site-wide effect) or ~/.profile (of course, the files are different for different csh and other shells). There is no good reason why XDM should be an exception here. Especially since there is no good replacement for it when using XDM. F.ex. where do *you* put such setups ? How many times do you hear complaints on some newsgroup that "foobar works from an xterm but not from the menu" and variants thereof ?
I believe your claim "it's not a bug" is clearly not backed by any convincing explanation since you presumed that I was using some kind of terminal emulator, which I'm not. Files like .login, /etc/profile , etc... are used to setup the session's environment, not some specific shell's environment and should thus be sourced whenever a session is started.
To be honest with you, I have not heard _anyone_ claiming that any program on the GNOME or KDE menu fails due to the claims you are making. There *may* be a problem perhaps. I have *yet* to see from you a specific example of an application that fails because of your claim. If you can provide me with a few SPECIFIC and easily reproduceable cases of this problem, then I will indeed test them and discuss it with others here and most likely come up with a solution. If this is indeed a generic bug with xdm/kdm/gdm, I would think I would have heard more about it by now... however, I suspect it is only an xdm problem, which is the only explanation I can think of for why I haven't heard anyone else mention anything as practically nobody uses xdm anymore. So... if you can give me a test case (preferably involving software that is part of the OS or powertools), but not necessarily - then I will try to reproduce it, and then possibly fix it if it does indeed misbehave.
First of all, I fully agree with the person who opened this bug: profiles should be _ALWAYS_ set up on logins be they graphical or text ones. As for an example of problems that arise when that does not happen, look at the LANG environment variable that is set up from Red Hat supplied /etc/profile.d/lang.sh. Setting this variable (in /etc/sysconfig/i18n) is absolutely vital to anyone who wishes to use any language or locale other than english. Another example is PATH, where $HOME/bin does not get appended because of this. Etc, etc, etc. For a full list of things that are set up (by Red Hat distribution itself!) in profiles please look at /etc/skel/.bash*, /etc/profile and /etc/profile.d/*. And then there are user's custom profile settings that do get ignored because of this. Log in via xdm, issue 'set' command and see for yourself! Also, I'm not suggesting a fix, because the fix above is very good. All exec's in /etc/X11/xdm/Xsession should be replaced in this way. Integrate it into the distribution please!
Also, you won't see this behaviour with gdm, because gdm executes Xsession itself with an '-' flag! Thus all profiles do get set up. But that's a hack, and it should go away (in my opinion). As for kdm, whether or not profiles are set up, depends on what session you're running: in failsafe they don't, in kde they do (because kde itself sets them up somewhere, not sure where exactly). This kde behaviour is a hack too and should go away as well :-)
I didn't know that GDM had such a hack. I agree that it's not satisfactory becuase it only works if your login shell is the same as the shell used to write the Xsession file. If you r shell is tcsh, your .login file won't be sourced (and the .bash_login will instead).
Well, it seems gdm tries to run Xsession with user's login shell. But according to bug #7860 this does not work - bash profiles are always executed.
Bug #35935 has a discussion of the same problem. It's not about running login shells in terminal emulators as Red Hat people seem to think. It's about setting up system-wide and user profiles on *dm logins that currently depends on what *dm and what graphical environment you happen to use.
*** Bug 35935 has been marked as a duplicate of this bug. ***
Ok, relax guys... it is just a bug, not the end of the world. ;o) I did not understand the problem, and wasn't about to go randomly changing things that I wasn't sure of that will affect millions of users. I wanted a "why" explanation and I have gotten one now. I think the request is reasonable, and will do something about it. No need to get all worked up over it. Think good positive thoughts now, knowing that you have helped whack a clue about X startup into my head. ;o) I don't use xdm/kdm/gdm so I'm rusty with that stuff. I will likely make this change along with numerous other change requests similar all at the same time at some point. Just so bero and hp know, when this change occurs, the Gnome and KDE startup may be affected. Note to self - "remind you guys later". ;o)
Hi guys, It could be nice to see the profile of user to be completely sourced with the same convention used on Solaris... Indeed if in .dt_something_ there's a variable called DTSOURCEPROFILE which can be true or false (default to true).... Like this if a user haven't have a bash login (some user of computers I make the administration have csh....or tcsh.....) it could have his profile sourced... I think you have to modify /etc/X11/xdm/xsession to make it work.... Just my 2 cents JY
Been fixed for a while now in Rawhide. Will be in final release of RHL 7.2.