First login in KDE is extremely slow (khotkeys_update)

Bug #293892 reported by kforum
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KDE Base
Fix Released
Medium
kdebase-workspace (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

the start splash, the one with the pretty pictures of an HD, all sorts of tools, and at the end the kde symbol, just hangs, on the live CD, the beta had the same issue and it remains...
its weird.

in the end you need to click for it to go...
when installed, the same happens, but if you wait some, it completes the splash animation and loads..

kforum (euro-fix)
description: updated
Revision history for this message
Stéphane Graber (stgraber) wrote :

Confirmed.

Starting KDE without a .kde/ hangs during 25+ seconds doing khotkeys_update.
Doing "sudo chmod -x /usr/lib/kconf_update_bin/khotkeys_update" workarounds the issue.

As it makes autologin to be extremely slow, I'm marking the bug priority as Medium.
Feel free to ask for any test you'd like me to do.

Changed in meta-kde:
importance: Undecided → Medium
status: New → Triaged
description: updated
Revision history for this message
Stéphane Graber (stgraber) wrote :

http://paste.ubuntu.com/70507/

For a trace with timestamps of the first steps of KDE4 login with a new user account.
When we then did something similar for /usr/lib/kde4/libexec/kconf_update it appeared it's khotkeys_update that's trying to load all the KDE4 libraries/daemons taking over 25s to do so. Doing the same with an existing account, takes less than a second to run. (No disk I/O or CPU usage appear when khotkeys_update is hanging)

Revision history for this message
Vincent Vinet (vince-vinet) wrote :

#kde-devel folks linked me to a bug in kde related to this
http://bugs.kde.org/show_bug.cgi?id=160892#c63

Commit 881249 mentions a deadlock at first boot, which really seems to be the problem.

In fact, the problem is that when khotkeys_update runs in startkde, kded, dbus and klauncher are not running, but are required. So, khotkeys_update starts them and tries to communicate with kded via dbus, but a deadlock prevents it from loading fast enough.

I applied the 881249 patch, recompiled, replaced libkhotkeysprivate.so and khotkeys_update, but the problem stays so far.

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Maybe the old libkhotkeysprivate.so and khotkeys_update binaries were still cached in RAM?

Changed in kdebase:
status: Unknown → Confirmed
Changed in kdebase:
status: Confirmed → Fix Released
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

The khotkeys problem has been fixed, but kbuildsycoca can still make things slow. (https://bugs.kde.org/show_bug.cgi?id=172274)

Changed in kdebase-workspace:
importance: Medium → Wishlist
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Closing since the khotkeys bug was fixed. You can follow the wishlist for a spinner to show progress in the upstream bug report I linked to.

Changed in kdebase-workspace:
importance: Wishlist → Medium
status: Triaged → Fix Released
Changed in kdebase:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.