To sum up a long story: I have KDM setup to log me in automatically (and lock the screen). A couple of days ago, it stopped doing that, and instead greeted me with the login screen, asking for username and password. If I enter those correctly, the screen goes momentarily black, the nvidia logo is displayed for like half a second, or so, and then the same login screen is shown, with the fields cleared. If I enter the wrong credentials, the fields are cleared, but no screen re-drawing takes place. But, if first login at the console (with the same user), and only then login in KDM, then I login sucessfully.

What's more weird, is that if at the console, if I do a "sudo killall X" (running Archlinux here), then KDM respawns (as it is supposed to do) and *logs me in automatically*. Further, if after being logged in in the KDE session, I log out of the console session, and then log out of the KDE session, I *can't* loging back at KDM (it behaves like described above), until I log in at console, and then I can log in fine with KDM.

If you're confused, well, I'm even more so. The logs don't report anything out of the ordinary (or so it seems to me). Ideas? Thanks in advance.

What does ~/.xsession-errors say when you are booted out?

I'm not sure what you mean by "booted out". Here's what I did: after I got the login/pass prompt from KDM, I logged in from console, deleted ~/.xsession-errors, and logged out. Then, from KDM, I entered the correct login/pass hit enter, which failed as described in my original post. Then I logged in again from console, and cat'd .xsession-errors. The file was re-created, but was empty.

Given the NVidia logo briefly flashes, this is possibly a NVidia driver related issues. Have you tried checking /var/log/Xorg.*.log to see if there are any hints there as to why KDE is failing to start?

The nvidia doesn't flash *always* (I should have mentioned it earlier, sorry). Furthermore, there is something that shows up Xorg.0.log after login failure (related to acpi), but I suspect it's a symptom, rather than a cause. I did find out thought, that auth.log reports a failure like so (I've copied the log and added relevant comments):

Code: Select all

# login at kdm WITHOUT being logged in at console (which fails)
Apr  4 00:13:55 localhost kdm: :0[1094]: pam_unix(kde:session): session opened for user gauthma by (uid=0)
Apr  4 00:13:55 localhost kdm: :0[1094]: pam_unix(kde:session): session closed for user gauthma

# line appended after login at console
Apr  4 00:15:00 localhost login[797]: pam_unix(login:session): session opened for user gauthma by LOGIN(uid=0)

# appended after login at kdm (whilst logged in at console)
Apr  4 00:15:31 localhost kdm: :0[1159]: pam_unix(kde:session): session opened for user gauthma by (uid=0)
Apr  4 00:15:55 localhost polkitd(authority=local): Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session6 (system bus name :1.21 [/usr/lib/kde4/libexec/polkit-kde-authentication-agent-1], object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)


Does it help?

Is ConsoleKit running?

I'm not familiar with the workings of ConsoleKit; the Archlinux package is installed, and the command ck-list-sessions yields the following:

Code: Select all

k-list-sessions
Session3:
        unix-user = '1000'
        realname = ''
        seat = 'Seat1'
        session-type = ''
        active = FALSE
        x11-display = ''
        x11-display-device = ''
        display-device = '/dev/tty1'
        remote-host-name = ''
        is-local = TRUE
        on-since = '2012-04-04T08:59:43.635331Z'
        login-session-id = '1'
        idle-since-hint = '2012-04-04T09:00:14.056689Z'
Session4:
        unix-user = '1000'
        realname = ''
        seat = 'Seat1'
        session-type = ''
        active = TRUE
        x11-display = ':0'
        x11-display-device = '/dev/tty7'
        display-device = ''
        remote-host-name = ''
        is-local = TRUE
        on-since = '2012-04-04T08:59:49.931445Z'
        login-session-id = '4294967295'


(the console session is the one I need to be able to login with KDM, which is being started from inittab (and not from .xinitrc)). Does this answer your question?

It appears that the session is being opened then instantly closed.
Does your system have any non-standard PAM configuration to specify home directories, Kerberos settings, etc?

Do log files such as /var/log/messages or /var/log/secure (names depend on the distribution unfortunately) mention anything of relevance as to why the session is terminating?

NOTE: Ignore the rest of my post, my issue seems to have absolutely nothing to do with this one (had to disable desktop effects to solve mine).

Since I am experiencing a similar issue (my session crashes with the same X.org messages), I will continue this topic as if I were the original user.

bcooksley wrote:Do log files such as /var/log/messages or /var/log/secure (names depend on the distribution unfortunately) mention anything of relevance as to why the session is terminating?

Not sure if it is relevant, but around the time the session closed, in messages.log:

Jul 28 09:25:16 localhost dbus[616]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper)
Jul 28 09:25:16 localhost org.kde.powerdevil.backlighthelper: QDBusConnection: system D-Bus connection created before QCoreApplication. Application may misbehave.
Jul 28 09:25:16 localhost dbus[616]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'

Following the instructions I found in a topic in the Gentoo forums (I am using a desktop as the guy there), I’ve just disabled the Dim Display from Energy Saving, which should end with those three lines in the log. But I guess this is unlikely to be the cause of the session crashes. I guess I will find out soon enough.

No secure.log here.

Just as a comment for future searchers, the D-Bus messages you saw are normal behaviour - and are the result of KDE Power Management altering the brightness of the screen. In some cases, a special helper which has root permissions is needed to do this.