Odd KDM Login Problem

I’m running OpenSuSE 11.2 (most recent desktop kernel) and KDE 4.4 desktop. System works perfectly, but I am consistently presented twice with the KDM4 login screen after a reboot. I do not get “invalid login”, or any other error message. When I enter my password and hit “enter”, the screen goes blank, as if KDE is starting, but then I am taken back to the login. The second login always works. Please note that this only occurs after a reboot. If I log out and log back in, behavior is completely normal.
This is only a minor annoyance, but I would still like to trace down the problem and find the cause. I don’t know if this is a display manager problem, an “X” problem, or possibly a KDE startup problem.

Hm… if you wouldn’t be able to log in at all I’d say your /-partition is full. Might still be an issue, so check

df -h
du -h /tmp

You could watch kernel-messages while trying to launch KDE by hitting Ctrl + Alt + F10, maybe that’ll give us some more info (back to your original tty: Ctrl + Alt + F7).

I noticed this in 11.3 recently with 4.4.1 from factory. But it didn’t happen every time.
I have just deleted that install to put in place the next Milestone release M4.
So far all is well.
Try updating kde4 if you haven’t already.

Thanks for the suggestions. My / partition is 80% full, with 21GB available, so I don’t think that is a problem.
I can’t hit ALT-CTL-F10 quick enough to do any good. In the system logs, the only warnings that I don’t understand may or may not have anything to do with this problem. I’ll post them:

Mar 24 15:53:36 Opto rtkit-daemon[4708]: Failed to make ourselves RT: Invalid argument
Mar 24 15:53:36 Opto rtkit-daemon[4708]: Warning: Reached burst limit for user ‘1000’, denying request.

This is not any kind of a serious problem. As stated, first login from boot takes me back to the login screen. Second login always works perfectly. Any subsequent login without rebooting works as expected. It may be a small bug concerning KDM or KDE. I’ll just keep an eye on this thread and see if others are having similar problems. I wouldn’t lose any sleep over it. The next update may get rid of it.

This haven’t happened to me yet, but i’d try to create a new user and test the login with it. It may be caused by a setting from a previous KDE4 version config file in /home/username/.KDE4.

Ok. I did finally find an error that seems to fit the problem. “Cannot load consolekit”. The error was reported by KDM. You are correct that it is apparently in my user file. I logged in as root and didn’t see the problem. The next question would be, “What file might contain the settings on how KDM accesses consolekit?”

No idea, unfortunately. Perhaps someone more knowledgeable will chip in. Is consolekit installed? Is there an update for it in the update/kde4 repo?

The generic solution would be:

Create a new user (not root) and see if it works ok for said new user. If it does:

Logoff KDE, backup and replace whatever subdirectory in the new users .kde4 with the old (problematic) user equivalent subdirectory. I like to use midnight comander (mc, in the repos) as it is a norton-like file manager for the console.

Log back in kde and se if the problem appears. This way you can zero in the offending setup file and copy the new user file back to the original user. This way you won’t have to personalize KDE4 from scratch.

Take a look at the ,kde4 contents, usually by the directories/file names you can identify the probable culprits.

Good luck, and please post your findings if (when :)) you succeed.

P.S.: Note that your success logging as root may indicate a permissions problem. This is usually fixed in an update.

Just in case you wanna disable root logins in KDE4, edit the file /usr/share/kde4/config/kdm/kdmrc and uncomment the following line

#AllowRootLogin=false

Here is an update: I have the same problem on a different, albeit, identical machine. Logging in with a different account, including root, had no success. From a cold boot, the first login attempt almost always fails and the second is always successful.

This appears to be a known bug:
#562026 - kdm cannot open ConsoleKit session on first login attempt - Debian Bug report logs](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562026)

Here is an excerpt:

**After some hours of debugging, I finally found the cause of this bug. It is a
race condition, so no wonder why it is only reproducable on some systems.

What happens is:

  1. kdm (or whatever else, I can even reproduce the bug with dbus-send) tries
    to call a method from the /org/freedesktop/ConsoleKit/Manager object, using
    the org.freedesktop.ConsoleKit.Manager interface.
  2. ConsoleKit is not running, so dbus-daemon activates it.
  3. console-kit-daemon starts and registers the service.
  4. dbus-daemon recognizes the service registration, tries to find the Manager
    object, fails, returns error.
  5. console-kit-daemon registers the Manager object at the same time that dbus-
    daemon returns the error.**

Here is a temporary patch for Debian, but OpenSuSE doesn’t have that file to edit:

**A temporay fix waiting for the final one,(which wil be on debian
repository) would be to edit the /etc/init.d/kdm script and modify the
following lines:

case “$1” in
start)
if -e $DEFAULT_DISPLAY_MANAGER_FILE ] &&
“$HEED_DEFAULT_DISPLAY_MANAGER” = “true” ] &&
“$(cat $DEFAULT_DISPLAY_MANAGER_FILE)” != “$DAEMON” ]; then
echo “Not starting K Display Manager (kdm); it is not the default
display manager.”
else
echo -n “Starting K Display Manager: kdm”
# added by user
if “$(ps -e|grep /usr/sbin/console-kit-daemon)” = “” ];then
echo “.”
/usr/sbin/console-kit-daemon&
fi
#enf of modification
start-stop-daemon --start --quiet $SSD_ARGS – $ARG || echo -n "
already running"
echo “.”
fi
;;

the missing daemon is started by the kdm script if it’s missing
**

If I can learn how to make this patch work under OpenSuSE 11.2 then the problem would be solved until an update is issued.

The same problem disturbs me for months. Is there any solution?

My original installation of OpenSuSE 11.2 was as an upgrade of an 11.1 installation, which I have read in other forums, is not the preferred way to do things.
What I did was to backup everything and do a fresh install. The problem is gone, so I can only assume that the problem was caused by some kind of problem associated with the upgrade.
A complete re-install of the OS is a lot of work, but it did eliminate this problem as well as others, and my system is considerably faster that it was before.
I am not suggesting that everyone with this problem trash their OS and re-install, but I can say that it was the correct decision for me to do so.
I had posted earlier about a known Debian bug that seems to be identical to this. It stated that upgrading to a newer version of console-kit would fix the problem. But the version of console-kit the blog refers to is not yet available for OpenSuSE. If anyone responds to my earlier post with a solution, then it might be the better alternative for most.