KDM Failsafe Session - Not Working ?

[Forester]

Hi,

What is the Failsafe Session Type that you can select from the KDM login screen supposed to do ?

With Squeeze RC1, if I attempt to log in to a failsafe session, I am returned to the KDM login screen. This does not seem very failsafe to me but then I am not a desktop expert.

With Lenny (5.0.7), I get a single console window, which, I guess, at least gives one a chance of fixing whatever may be stopping the normal KDE session from starting.

[schmidtbag]

it should load the failsafe xorg settings. i'm not sure if it actually logs you in with those settings, it might just revert back to them. if you don't have a failsafe config file in /etc/X11/ then my guess would be that it doesn't work because its trying to load something that doesn't exist, and since the option is supposed to be fail SAFE, signing you in with undefined graphical settings isn't exactly safe.

[Forester]

Thanks schmidtbag for the suggestion. I have tried testing your hypothesis with the default xorg.conf from lenny. It seems to make no difference (neither did the absence of .default.face).

I can't see any errors in the systems logs. I can't see any difference between a failed failsafe login and a successful normal login except in auth.log:

Normal / successful:

Code: Select all

Jan 23 09:24:53 maple kdm: :0[3496]: pam_unix(kdm:session): session opened for user debian by (uid=0)
Jan 23 09:24:53 maple kdm: :0[3496]: pam_ck_connector(kdm:session): nox11 mode, ignoring PAM_TTY :0
Jan 23 09:24:58 maple polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session7 (system bus name :1.70 [/usr/lib/kde4/libexec/polkit-kde-authentication-agent-1 -session 10d261706c000129503571800000026180009_1295774675_620129], object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)                             
Jan 23 09:25:27 maple polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session7 (system bus name :1.70, object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)
Jan 23 09:25:27 maple kdm: :0[3496]: pam_unix(kdm:session): session closed for user debian


Failsafe / failure:

Code: Select all

Jan 23 09:25:39 maple kdm: :0[3983]: pam_unix(kdm:session): session opened for user debian by (uid=0)
Jan 23 09:25:39 maple kdm: :0[3983]: pam_ck_connector(kdm:session): nox11 mode, ignoring PAM_TTY :0
Jan 23 09:25:39 maple kdm: :0[3983]: pam_unix(kdm:session): session closed for user debian


which may mean something to an expert but tells me nothing.

I do think the X-session started correctly for in the user's .xsession-errors I have:

Code: Select all

Xsession: X session started for debian at Sun Jan 23 09:17:37 GMT 2011
konsole(2728)/kdeui (kdelibs): Attempt to use QAction "change-profile" with KXMLGUIFactory!
x-terminal-emulator: Fatal IO error: client killed
kDebugStream called after destruction (from virtual Konsole::SessionManager::~SessionManager() file ../../../../apps/konsole/src/SessionManager.cpp line 301)
Konsole SessionManager destroyed with sessions still alive


This brings me back to my original question.

The trace above suggests Konsole session manager has tried to do something it shouldn't but I am wondering if it should be running at all. Under lenny with KDE 3.5, the output of ps in a failsafe session shows x-terminal-emulator is running but there is no konsole process.

The kdmrc files for both lenny and squeeze contain:

Code: Select all

# The program to run if Session fails.
# Default is "/usr/bin/xterm"
#FailsafeClient=


so I was naïvely surprised that x-terminal-emulator is running and not plain old xterm.

I have tried changing kdmrc to make the 'default' explicit but to no effect. I have tried changing kdmrc under /etc/kde4/kdm and the copy under /var/run/kdm.

The question now becomes is there a way to change what the failsafe session runs and, if so, what is it ?

[schmidtbag]

at this point i have no idea, but honestly at this point would it really matter? usually failsafe is only necessary when you have a fresh new install or if you got ALL new hardware, and even then i find it much easier to use the console login and fix from the command line. from what i recall, i don't remember failsafe working for me either. from a command line, you can easily modify your xorg.conf via nano and just run "startx" from there and you get yourself a more effective failsafe.

keep in mind that even debian's unstable, testing, and experimental repos are still VERY far behind with kde, this issue could actually be fixed but WE will never find out because for some stupid reason the devs are anal about making sure things are stable for them, when the kde devs say something along the lines how kde 4.5 and 4.6 were just simply a massive list of bug fixes and some additional widgets. as soon as something breaks my install, i'm switching to arch because i have absolutely had it with how debian's unstable and testing repos still give us stuff thats literally almost an entire year old at this point.

[BioTube]

Is xterm installed? It doesn't seem to be included by default anymore, so it might be your session's closing when there's nothing to run. As for "failing safe", X should default to vesa or fbdev, both of which are generic drivers guaranteed to work on almost all hardware.

[Forester]

Is xterm installed? It doesn't seem to be included by default anymore, so it might be your session's closing when there's nothing to run.

I agree with your point that if xterm (or whatever the failsafe login tries to run) is missing then the session would close immediately and that would explain what I am seeing. I can 't say whether xterm was installed originally but I did succeed in starting a twm session and created an xterm from there and think that was before I installed any extra packages whatsoever. In any case, xterm is certainly installed now and it makes no difference. I installed xdm and found I could get to an xterm based failsafe session that way. I switched back to kdm and I'm back to square 1.

As for "failing safe", X should default to vesa or fbdev, both of which are generic drivers guaranteed to work on almost all hardware.

Your statement makes perfect sense to me but that is not what I observed. I started by asking if anyone knew what should happen. There is no point submitting a bug report that is so far from the mark it just gets ignored.

I got into this mess by upgrading lenny to squeeze on a machine with a SIS graphics chip set. It seems the (squeeze) sis driver crashes when a KDE session is closed. After the upgrade, for reasons unknown, the KDM greeter was set to failsafe session. So the first time I attempted to log in the session closed immediately and the X server crashed. This same thing happen with the upgrade of two more machines and it seemed to me KDE was very, very broken. Only when I thought I'll try a failsafe session did I discover that failsafe seemed to be part of the problem.

Now I'm looking into this problem using a machine with an Intel graphics chip set and there is no crash when a KDE session is closed: starting a failsafe session simply returns me to the login screen. If failsafe mode were using vesa or fsdev then I would expect behaviour on the Intel machine to be the same as one the SIS machines (but I'm no expert).

at this point would it really matter?

To those who know what they are doing, perhaps not, which is why such issues don't get fixed. To someone like myself, so long as I learn something from looking at the problem, it's fine. If I was not interested in learning I might still be using a commercial operating system. To a newbie, what I experienced would be enough for them to submit a bug report that would get laughed and that would be enough to persuade them to go elsewhere.

from a command line, you can easily modify your xorg.conf via nano and just run "startx" from there

See ... I've learnt something useful. Thank you very much for the tip.

i'm switching to arch

Perhaps Debian is not the best distribution for KDE fans. In which case, I'm definitely posting in the wrong forum !

If I changed distribution every time something went wrong I'd be installing a new one every week. I might even be trying the Great Brown distribution again. Good grief !

[BioTube]

Now I'm looking into this problem using a machine with an Intel graphics chip set and there is no crash when a KDE session is closed: starting a failsafe session simply returns me to the login screen. If failsafe mode were using vesa or fsdev then I would expect behaviour on the Intel machine to be the same as one the SIS machines (but I'm no expert).

The server's already loaded when the display manager starts(thus loading whatever driver it's going to load); the failsafe session deals with errors in starting a user session, not bugs in the server itself(although you might want to install a simple window manager like Openbox to use instead).

[schmidtbag]

at this point would it really matter?

To those who know what they are doing, perhaps not, which is why such issues don't get fixed. To someone like myself, so long as I learn something from looking at the problem, it's fine. If I was not interested in learning I might still be using a commercial operating system. To a newbie, what I experienced would be enough for them to submit a bug report that would get laughed and that would be enough to persuade them to go elsewhere.

from a command line, you can easily modify your xorg.conf via nano and just run "startx" from there

See ... I've learnt something useful. Thank you very much for the tip.

i'm switching to arch

Perhaps Debian is not the best distribution for KDE fans. In which case, I'm definitely posting in the wrong forum !

If I changed distribution every time something went wrong I'd be installing a new one every week. I might even be trying the Great Brown distribution again. Good grief !

idk, i tend to know what i'm doing but sometimes you just gotta deal with the little problems you encounter. i admire your ambition and willingness to learn, you remind me of myself when i first started using linux. but since linux gets broken so easily, you tend to just need to find alternative solutions which is why i told you about logging into a graphical interface thru the command line. currently, i have issues where kwin compositing constantly causes kwin and xorg to tax the cpu. apparently newer versions of kde 4 don't tend to do this, and compiz doesn't do it either. since there is absolutely nothing i can do with what *i* want as of right now, its either turn off kwin compositing (which i use for practical purposes, not eye candy), use compiz, or somehow get debian to bring kde from 4.4.5 to 4.6.x.

interestingly, your comment about choosing to be ignorant and pick a commercial product is similar to picking a commercial product to avoid the problems you would have questions about in the first place. debian is designed to be stable but packages are modified every day, and the debian dev team has to test them if they're stable enough when in actuality, these newer packages could be much more stable. unfortunately, they're caught behind seeing if the previous version is stable, so debian is always going to be behind. i've been told debian isn't the best choice for kde. as i see it, its the best distro for desktop environments that are either simple or don't get updated often such as xfce, lxde, openbox, kde 3, gnome 2, or any kind of server. but if you want cutting-edge (like what kde 4 or gnome 3 is) then you need to look elsewhere, which is what i'll be doing eventually.

[Forester]

Thanks to you both for your input. I am afraid I don't get much time for this kind of thing during the week.

To summarise (and lay this this topic to rest):

- KDM failsafe login under squeeze most likely isn't working as it should
- the Debian project will only fix issues the project introduced
- if I knew how to prove / disprove this issue is a Debian issue I would not be asking questions on this forum.

Catch 22 but thanks anyway.