Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 286378 - kdm(-4.3.1) does not provide a fallback for "custom" session when .xsession not set
Summary: kdm(-4.3.1) does not provide a fallback for "custom" session when .xsession n...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo KDE team
URL: http://svn.reviewboard.kde.org/r/6236/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-25 08:37 UTC by kavol
Modified: 2011-04-12 22:32 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---
tampakrap: Bugday+


Attachments
xsession error file for the x86 (.xsession-errors,3.27 KB, text/plain)
2011-03-27 09:09 UTC, Geoff Madden
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kavol 2009-09-25 08:37:27 UTC
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
Comment 1 Andreas K. Hüttel gentoo-dev 2010-08-29 11:20:04 UTC
Is this still an issue with kde-4.4 or kde-4.5?
Comment 2 kavol 2010-09-10 17:53:35 UTC
(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
Comment 3 Theo Chatzimichos (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2010-12-30 01:09:39 UTC
slightly modified patchreported upstream in http://svn.reviewboard.kde.org/r/6236/ i'll wait for their feedback and act accordingly. thank you!
Comment 4 Oswald Buddenhagen 2011-03-05 16:44:52 UTC
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.
Comment 5 Andreas K. Hüttel gentoo-dev 2011-03-05 18:16:22 UTC
(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...
Comment 6 Theo Chatzimichos (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2011-03-05 18:21:42 UTC
(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
Comment 7 Oswald Buddenhagen 2011-03-05 18:49:04 UTC
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.
Comment 8 kavol 2011-03-05 20:10:25 UTC
(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? :-)
Comment 9 Geoff Madden 2011-03-27 09:09:54 UTC
Created attachment 267365 [details]
xsession error file for the x86
Comment 10 Andreas K. Hüttel gentoo-dev 2011-04-12 22:32:44 UTC
(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 :|