I've finished yesterday updating two machines to the latest ~x86 packages. Afterwards I've found out that I was unable to login with my usual user in either computer. I was using before the update the kde-3.2.2 and kde-3.2.3 in each of the computers without problem. After many tests, including removing the user's .kde* .qt* .mcop .dcom directories, the /tmp/mcop-<user> directory, restarting the systems, looking at the /etc/pam.d/ configuration and at the /etc/security/ details, I've finally discovered that the problem was related to the fact my user uses tcsh. In my testing, I noticed that root was able to login and therefore thought I had the #48886 bug. After rebooting and confirming that I had a diferent problem , I created a new user and tried to login via kdm - sure enough I was able to login. Then I created another user and copied my remaining /home dir to this user. Surprisingly, I was also capable to login. Finally, I remembered that I use tcsh and not bash and decided to try it. I've thus found the culprit - tcsh and kdm. I can confirm that after creating a clean user, if one sets tcsh as the shell, one cannot login via kdm. As soon as one replaces tcsh by bash the problem disappears. Unfortunately, one cannot return to tcsh because it becames again impossible to login via kdm. Reproducible: Always Steps to Reproduce: 1. emerge the kde-3.3.0 packages 2. create a new user with useradd -m -s /bin/tcsh <user> 3. try to login via kdm 4. replace the shell in /etc/passwd to /bin/bash 5. login via kdm To clear all doubts: 6. replace the shell in /etc/passwd to /bin/tcsh 7. try to login via kdm again Actual Results: When one tries to login via kdm using tcsh, kdm tries to start the wm, fails, restarts and presents the kdm login screen again. The only relevant log messages appear in /var/log/messages: Sep 6 17:58:07 atlantida kde(pam_unix)[7776]: session opened for user atlantis by (uid=0) Sep 6 17:58:07 atlantida kde(pam_unix)[7776]: session closed for user atlantis Sep 6 17:58:07 atlantida mtrr: 0xd8000000,0x4000000 overlaps existing 0xd800000 0,0x200000 Sep 6 17:58:11 atlantida kdm_greet[8128]: Can't open default user face Expected Results: Allowed me to login via kdm. I believe that this problem with kdm might be caused by an kde/kdm init script that doesn't run with tcsh - perhaps it requires bash. As I see it, it prevents anyone from using tcsh and running kde-3.3.0. Follows the emerge info on one of the computers (the major difference on the other is that I have compiled a 2.6.8-r3 kernel): atlantida atlantis # emerge info Portage 2.0.50-r10 (default-x86-2004.0, gcc-3.3.4, glibc-2.3.4.20040808-r0, 2.6.7-gentoo-r6) ================================================================= System uname: 2.6.7-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa apm arts avi berkdb cdr crypt cups dvd emacs encode esd fbcon flac foomaticdb gd gdbm gif gnome gpm gtk gtk2 imap imlib ipv6 jabber java jikes jpeg junit kde ldap libg++ libwww mad memlimit mikmod mmx motif mozilla mpeg mule mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba scanner sdl slang spell sse ssl svga tcltk tcpd tiff truetype unicode usb wmf x86 xml xml2 xmms xv zlib" atlantida atlantis #
There's some tcsh specific code in /usr/kde/3.3/share/config/kdm/Xsession Make sure you have the most recent copy of that file and then try to see if commenting out something there makes a difference. If you have some strange content in ~/csh.login and ~/.login it could matter, too.
Gregorio, thanks for your suggestions. I've been able to solve the problem that way. I started looking at /usr/kde/3.3/share/config/kdm/Xsession and didn't see anything that appeared to cause the behaviour. By the way here is the relevant part: */csh|*/tcsh) # [t]cshrc is always sourced automatically. # Note that sourcing csh.login after .cshrc is non-standard. set -a eval `$SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c set | egrep -v "^(BASH_VERSINFO|EUID|PPID|UID|_)="'` set +a ;; Next, I looked at /etc/csh.cshrc, /etc/csh.env and /etc/csh.login. I didn't change any of them, so I still have the original config files and I have tcsh 6.12-r3, I don't have ~/.csh.login or ~/.login files. Finally, I looked at ~/.tcsh.config. On one computer I had a missing new line in the end of the file - after chaging it the problem was gone. But on the other I can't see the problem. This is the fault ~/.tcsh.config; /home/atlantis> cat .tcsh.config ## ## TCSH Configuration ## ## The setting in this file influence the behaviour and configuration ## of the base tcsh scripts. ## ## 2003-01-14 -- Alain Penders (alain@gentoo.org) ## Initial version ## # # Will pressing CTRL-D exit the shell? # # Value: set to enable CTRLD, unset to disable. (Default: enabled) # setenv TCSH_SHELL_CTRLD 1 # # Will the history be saved for the next session when the shell is closed? # # Value: set to enable saving the history, unset to disable. (Default: enabled) # setenv TCSH_SHELL_SAVEHISTORY 1 # # Auto-logout after a certain number of minutes? # # Value: unset to disable, set to the number of minutes to enable. (Default: disabled) # #setenv TCSH_SHELL_AUTOLOGOUT 15 # # Default rm, mv, and cp to safe versions (ask before overwriting or deleting afile)? # # Value: set to enable, unset to disable. (Default: set to protect new users) # setenv TCSH_SHELL_SAFETY 1 # # Add MSDOS/CPM command aliases (del, cls, md, rd, dir)? # # Value: set to enable, unset to disable. (Default: disabled) # #setenv TCSH_SHELL_DOS 1 # # Add CD shortcut aliases? # # These include: # . -> pwd # .. -> cd .. # ../ -> cd ../ # - -> cd - # / -> cd / # # Value: set to enable, unset to disable. (Default: disabled) # #setenv TCSH_SHELL_CDALIAS 1 # # Enable intelligent command line completion (by pressing TAB)? # # Value: set to enable, unset to disable. (Default: enabled) # setenv TCSH_SHELL_COMPLETION 1 /home/atlantis> Can you see any problem with the file? Thank you for your help. Jorge.
I see nothing strange... can you confirm that with the above ~/.tcsh.config login fails but without it or with an empty one login succeeds?
Gregorio, Yes, I can. I've tried putting in and out the ~./tcsh.config and I can login via kdm without it and cannot with it. I've just stumbled into something that worsens the problem. After removing ~/.tcsh.config and logging via kdm, the "kdm/kde" startup process automatically creates a ~/.tcsh.config exactly identical to the one I've posted. When I log out and try to login again, kdm blows up, as before.
That's weird. ~/.tcsh.config reappears because it is copied from /etc/skel/.tcsh.config, by the /etc/csh.cshrc script. And it is sourced, too (see /etc/csh.cshrc again), but one time kdm fails, and the other time kdm succeeds, even if both times the same .tcsh.config is sourced. The only difference is that when .tcsh.config is missing, the line in Xsession $SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c set | egrep -v "^(BASH_VERSINFO|EUID|PPID|UID|GROUPS|SHELLOPTS|_)="' produces extraneous output: it prints at the beginning: >>> Copying /etc/skel/.tcsh.config to your home directory ... >>> Please edit it to fine-tune the TCSH behaviour. (this is a bug of /etc/csh.cshrc, it should not produce output) this breaks the subsequent 'eval' command, and this magically makes kdm work! maybe the 'eval' command sets some variable that confuses kdm afterwards? You should try with an existing but empty .tcsh.config, and then start putting debug statements in /usr/kde/3.3/share/config/kdm/Xsession and in /usr/kde/3.3/bin/startkde to find the exact point at which the startup process stops.
I'm unable to login via kdm with an empty ~/.tcsh.config. I've also confirmed that despite my previous belief after several experiments, I'm unable to login in both computers. It seems that I had changed the shell back to bash, when I thought I was still using tcsh. I was concentrating on the differences between both machines to get to the solution. :-( That won't do. After reading your explanation and looking better at the files, I've decided to try bit by bit and see what I could find out. I've started by looking at the /usr/kde/3.3/share/config/kdm/Xsession and trying the commands for the tcsh shell. I've found out some interesting output for the inner construct: /home/atlantis> /bin/sh -c set | egrep -v "^(BASH_VERSINFO|EUID|PPID|UID|_)=" ... HOSTTYPE=i386-linux IFS=' ' INFOPATH=/usr/share/info:/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info ... XINITRC=/etc/X11/xinit/xinitrc /home/atlantis> I believe that the two lines IFS=' and ' may causing some problems. Here is the output of the external construct: /home/atlantis> $SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login; if (-f~/.login) source ~/.login; /bin/sh -c set | egrep -v "^(BASH_VERSINFO|EUID|PPID|UID|GROUPS|SHELLOPTS|_)="' Bad : modifier in $ (/). ... HOSTTYPE=i386-linux IFS=' ' INFOPATH=/usr/share/info:/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info ... XINITRC=/etc/X11/xinit/xinitrc /home/atlantis> The result "Bad : modifier in $ (/).", which I also obtain if logging in on a console, may be causing some problems. What I can't understand is where does the: IFS=' ' come from? If I do a setenv on a console, I don't get any IFS. Due to their large size, I'm attaching the complete output from both constructs and the setenv on the following comments. If this isn't at all relevant, where should I concentrate? On the /etc/profile.d/tcsh-* files? On the /usr/kde/3.3/bin/startkde? Thank you.
Created attachment 39144 [details] The result of executing the inner construct on the konsole.
Created attachment 39145 [details] The result of executing the outer construct on the konsole.
Created attachment 39146 [details] The result of executing setenv on the konsole
IFS should not be a problem, it's a bash builtin variable. You should find some construct like this in your config files: setenv PATH $PATH:/foo because this causes the error (try "echo $HOME:/foo" in a console) maybe in /etc/csh.env, which is autogenerated by env-update?
If the problem is not IFS then I'll move forward after the origin. I've searched for some command that did a 'setenv VAR $VAR:...', but was unable to find any. I've searched on /etc/csh.*, /etc/profile.d/*, /usr/kde/3.3/share/config/kdm/* and /usr/kde/3.3/bin/startkde. I'm going to post them as attachments on the following comments in case it helps. The /etc/csh.env defines the PATH as: setenv PATH '/usr/local/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.2_rc1/bin:/opt/blackdown-jdk-1.4.2_rc1/jre/bin:/usr/qt/3/bin:/usr/kde/3.3/bin:/usr/kde/3.2/bin:/opt/HelixPlayer:/usr/qt/2/bin:/usr/games/bin:/opt/vmware/bin' I can't see any problem with this definition. At least I don't get the error message that I get when I try to do something as "echo $VAR:...". I've received an email from Benjamin Foote calling my attention to a bug report opened on the debian list that seems to be related if not the same. The address is the <a href="http://lists.debian.org/debian-qt-kde/2004/08/msg00430.html">following</a>. They refer three variables GROUPS, DIRSTACK and SHELLOPTS. The first and the last are already filtered by the expression. To test I've modified the Xsession script to filter the other one. Unfortunately, it didn't work. Can you give me anymore pointers? What can I do or test? Thank you.
Created attachment 39163 [details] The /etc/csh.cshrc file
Created attachment 39164 [details] The /etc/csh.env file
Created attachment 39165 [details] The /etc/csh.login file
Created attachment 39166 [details] The /etc/profile.d/tcsh-aliases file
Created attachment 39167 [details] The /etc/profile.d/tcsh-bindkey file
Created attachment 39168 [details] The /etc/profile.d/tcsh-complete file
Created attachment 39169 [details] The /etc/profile.d/tcsh-settings file
Created attachment 39170 [details] The /usr/kde/3.3/share/config/kdm/Xsession file
Created attachment 39171 [details] The /usr/kde/3.3/bin/startkde file
I really don't know. All you could do is search if you some other of the variables in attachment 39145 [details] are readonly and should be filtered (you can test with "declare -p VAR" and see if the 'r' appears), maybe because you use bash-3 or because they were set readonly elsewhere... and make sure that you can login if you remove completely the 'eval' line in Xsession, just to be sure the problem is there.
after 3 hours of testing: IFS is the problem... /usr/kde/3.3/share/config/kdm/Xsession: eval `$SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c set | egrep -v "^(BASH_VERSINFO|EUID|PPID|UID|_|IFS)=" '` this works fine for me. i dunno y IFS is the problem... i thought there is an unmatched ' - but removing other variables which use ' don't work while IFS does. so for my box it's for sure that IFS is the evildoer. i still can't find a reason because executing the eval commands on the shell works with and without IFS.
Florian, I can confirm this. After all my tests, I only had to add IFS to the filter and I could login again again via kdm with tcsh as my shell!!! :-) Thank you! Gregorio, I followed your suggestion and tried all the variables that were being passed with the eval statement, but was unable to find any which was read-only. Most were -- and some were -w, but none was -r.
sorry for the misleading suggestion :P I'm glad it's solved, now if only I could unsderstand what's happening... :)
Gregorio, there's nothing to forgive, only to thank! ;-) I also wish I could understand the problem. Jorge.
I can confirm the same problem here too. KDM 3.3 and the user having a shell of tcsh are a no go. Adding IFS to the eval line in /usr/kde/3.3/share/config/kdm/Xsession worked.
I had this same problem and also tracked it down to the /bin/sh -c set line. If you have a newline in your IFS variables (so it splits across two lines), it's not a problem for Bash to parse. Adding "IFS" to the egrep line I think creates a syntax error which has the side-effect of allowing the login. The egrep line doesn't correctly handle multi-line variables. The problems with my setup was the SHELLOPTS variable (read-only) and GROUPS (not sure why but probably because it is some kind of array). When I egrep'd those out it worked. So my egrep contains: BASH_VERSINFO|SHELLOPTS|GROUPS|EUID|PPID|UID|_ I also noticed that if you use "/bin/bash -c set ...." instead of /bin/sh, it will return the multi-line variables as a single line with embedded newlines, which makes the egrep a bit more reliable. I haven't played with it since but I bet some kind of hack with exec might be a more reliable way to bring the variables over, something like: if [ -z "$__KDE_EXEC_HACK" ]; then exec $SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; setenv __KDE_EXEC_HACK yes; exec "'$0'"' fi
At last! :-) This problem was driving me crazy. Everything worked again after adding '|IFS' to the list of environment variables in /usr/kde/3.3/share/config/kdm/Xsession as discovered by Florian Fruth. Thanks Florian!
It was time to report this bug to kde people: http://bugs.kde.org/show_bug.cgi?id=90593
After some more testing: awk is right, adding IFS is not the right solution. I think that for the majority of people the solution is to add SHELLOPTS and GROUPS to the list of filtered variables, as said here: http://lists.debian.org/debian-qt-kde/2004/08/msg00430.html and as it's currently being done in kde CVS. In this bug we were lead to the wrong path because that didn't work for the original reporter, but he seems to be the special case here... ;)
The SHELLOPTS/GROUPS patch does not work for me. After modifying /usr/kde/3.3/share/config/kdm/Xsession I am able to login, but everything will run in English instead of German language, which I specified $LANG and $LINGUAS. I guess /etc/profile doesn't get sourced properly, since everything's ok when I start KDE from the console or by using xdm to login. My workaround is to use the Xsession script from the previous KDE 3.2.2, which works just fine for 3.3.0. Maybe someone can verify if this is Gentoo specific or a general problem of KDM/KDE.
Stefan, /etc/profile is a bash specific file and does not get sourced by Xsession if it finds that your shell tcsh. It should source /etc/csh.env though, which is generated by /etc/env.d with env-update (check that you have LANG defined there). Can you try adding if (-f /etc/csh.cshrc) source /etc/csh.cshrc; before if (-f /etc/csh.login) source /etc/csh.login; in Xsession and see what happens?
My fault. I didn't know that /etc/profile is bash specific, as it's mentioned nowhere in the documentation. Pretty weird naming scheme, "profile" does by no means sound bash specific to me, and the docs are always talking about /etc/profile as THE place for global environment settings. Anyway, I took all my manual variable definitions from /etc/profile and put them into a new file in /etc/env.d, now the patched Xsession script from KDE 3.3.0 works just fine. The modifications from your latest post are NOT required. Just as it's stated in the Xsession script, the csh-configs automatically get sourced properly. The old (3.2.3) Xsession script sourced /etc/profile, no matter which shell one was using, that's why I didn't notice my misconfiguration. Did the SHELLOPTS / GROUPS modification make it into the new KDE 3.3.1? If that's considered to be the "clean" way of fixing this issue and there are no more complaints about this, we might close this bug now.
It might be that bug 68663 is related to this. Had anyone else, who used the above fix to use tcsh together with kdm, problems when 'su'ing within a xterm and then executing scripts like rc-update or emerge?
YES! I'm experiencing exactly the same problems you described in bug 68663. Thanks to a completely broken emerge (always told me something about "'debug-print': not a valid identifier") and a dozen udev problems, I just reinstalled Gentoo from scratch. Today I changed my portage profile from default-x86-2004.2 to default-linux/x86/2004.2, as suggested by portage after an emerge sync. This change threw me back to where I was some weeks ago: A broken system unable to emerge anything. Thanks to your other bug report I am now able to emerge again! But only if I login on a console, NOT on a xterm and/or through su'ing in a xterm. I never thought this POSIXLY_CORRECT-bastard caused all my troubles, what a waste of time! Anyway, I would really like to know if the profile change caused the POSIXLY_CORRECT to be set, or if it was enabled before. Baselayout/portage didn't change during my profile change, I just modified the link in /etc/make.profile. I'll try baselayout-1.11.5 now, anyway, hope it will fix some udev troubles.
Wow, crapocalypse! Just DON'T use baselayout-1.11.5, please. I've never seen that many error messages at boot time in my whole life. And they kept repeating... repeating... repeating.... just until the machine rebooted. Itself. Automatically. Oh my god. You've been warned...
Yet another update, might be useless nonsense though: (note: root shell is bash, user shell is tcsh) To make emerge run in xterm again and to have df show 1k blocks instead of 512b blocks (which also depends on the POSIXLY_CORRECT setting), I added POSIXLY_CORRECT="" to /etc/env.d/99local. I thought it would also unset that variable, which it doesn't. Then I added "unsetenv POSIXLY_CORRECT" to /etc/csh.cshrc and "unset POSIXLY_CORRECT" to /etc/profile. Now df would show the correct output, but emerge still wouldn't work. After removing the entry in /etc/env.d/99local both df and emerge work fine. I rebooted several times and tried to emerge one package again and again, with always the same results: POSIXLY_CORRECT not unset anywhere: df output wrong, emerge doesn't work. POSIXLY_CORRECT unset in shell configs and 99local: df fine, emerge doesn't work. POSIXLY_CORRECT unset in shell configs only: df fine, emerge works. This might or might not be useful information, and the above rules might or might not apply after another 100 emerges, but I found it somewhat strange and worth mentioning.
All should be ok now, reopen if not.
