Hi. Recently, it happened to me that I was unable to log-in any user via kdm. What I have found was that the system has decided that every user uses the "custom" option for choosing the session type. (It looks like another bug, but I'd have to investigate further, and to be honest, I'm a bit lazy to do so, as I am completely clueless where does this configuration come from ...?) As the kdm intro screen does not indicate which session type is chosen, I had been wondering why it just keeps restarting over and over immediately after entering the login info. Reading the logs, I had found that the restarts are caused by ~/.xsession missing => not executable. Tracing back to the file/line indicated where the error happens, I have found that the "custom" case is chosen in /usr/share/config/kdm/Xsession But the script does not check in any way if it is a valid choice. I'd suggest adding something like the following patch, which falls back to running the default session type if the custom configuration (script) file ~/.xsession does not exist: --- Xsession~ 2009-09-24 12:22:22.000000000 +0200 +++ Xsession 2009-09-24 08:10:05.000000000 +0200 @@ -53,8 +53,11 @@ exec xterm -geometry 80x24-0-0 ;; custom) - exec $HOME/.xsession - ;; + if [ -f $HOME/.xsession ]; then + exec $HOME/.xsession + exit + fi + ;& default) exec /usr/bin/startkde ;; Reproducible: Always Steps to Reproduce: 1. delete your ~/.xsession 2. on kdm login screen, choose custom session type 3. try to login Actual Results: the user is not logged in, kdm login screen reappears Expected Results: the session type falls back to "default" and the user is logged in or, alternatively, a message that "custom" is not a valid choice appears, so that the user can read it before the next login try while I have no system to test right now, I believe this is a regression from KDE3 times, when choosing custom session without configuring it led to running the default session
Is this still an issue with kde-4.4 or kde-4.5?
(In reply to comment #1) > Is this still an issue with kde-4.4 or kde-4.5? yes, with kde-base/kdm-4.4.5 the problem is the same - choosing "custom" leads to the login screen reappearing without any error message
slightly modified patchreported upstream in http://svn.reviewboard.kde.org/r/6236/ i'll wait for their feedback and act accordingly. thank you!
the Xsession should display a message box if the session cannot be executed. kdm's default Xsession uses the xmessage tool for that - if that one is missing, the problem will go unreported. so one can make kdm depend on xmessage or modifiy the script to support both kdialog and xmessage and depend on xmessage|kdebase-apps.
(In reply to comment #4) > the Xsession should display a message box if the session cannot be executed. > kdm's default Xsession uses the xmessage tool for that - if that one is > missing, the problem will go unreported. so one can make kdm depend on xmessage > or modifiy the script to support both kdialog and xmessage and depend on > xmessage|kdebase-apps. > This is strange because we have the dependency already in all in-tree versions...
(In reply to comment #5) > This is strange because we have the dependency already in all in-tree > versions... Oswald is the upstream kdm developer, he is talking about kdm itself not about our depedencies :) Anyway, I'll try to update the patch
no, i actually meant packages. kdm itself doesn't check the xmessage dependency anyway (which is admittedly a bit sloppy). upstream it would make sense to just switch to kdialog, as somebody installing from source will most likely install all of kdebase anyway.
(In reply to comment #5) > This is strange because we have the dependency already in all in-tree > versions... I've just checked the machine, and it has xmessage installed ... however, checking emerge.log, it got installed on 1291754002 i.e. December 2010 - so, *after* comment #2 unfortunately, I don't have physical access to that machine now so I can't re-test (unless I figure out how to do that remotely ... any hints? :-)
Created attachment 267365 [details] xsession error file for the x86
(In reply to comment #8) > I've just checked the machine, and it has xmessage installed ... however, > checking emerge.log, it got installed on 1291754002 i.e. December 2010 - so, > *after* comment #2 OK, let's assume this is fixed then by installing xmessage... > unfortunately, I don't have physical access to that machine now so I can't > re-test (unless I figure out how to do that remotely ... any hints? :-) No idea :|
