When logging in to KDE from KDM, about half the time there is a really long pause, maybe 40 seconds, before the KDE menus or any of the taskbar operations work, and before the saved session state is restored. The other half of the logins, everything pops up and is fully operational more or less right away, within a few seconds.

This doesn't seem to depend on the saved session. Even if nothing has to be restored and the login is to an empty desktop, the same thing happens. It also isn't related to disk caching: I can login 10 times in a row and some are fast, some are slow. It happens even for newly created users. Unlike windows, this doesn't seem to be an intrinsic property of KDE, because some cases ARE fast.

How can I figure out what's causing the delay, for the slow cases? It's a bit annoying! I've tried looking in .xsession-error but that always has so much **** in it that it's really hard to know what shouldn't be there. I wish that really was for errors, so you'd know anything in there was a problem. But on a new install, freshly made user, it's still loaded up with cr*p.

Thanks...

Can you log through console while the login is running and see whether a process is hogging up the CPU? Is your setup using network-based partitions, such as /home on NFS or similar?

Can you log through console while the login is running and see whether a process is hogging up the CPU? Is your setup using network-based partitions, such as /home on NFS or similar?

OK, just tried. During this period, there is no significant CPU activity on any core. The most usage is htop on VT6, taking 1-2%. All other cores are at 0%.

/home is locally mounted and there should be no NSF mounts involved.

In the process of trying your experiment, I did notice that if I switch from VT6 (text) back to VT7 (graphics), the KDE taskbar does not get repainted until the moment when I can interact with it again. The rest of the screen repaints, including the desktop widgets and the wallpaper, but the task bar does not. It's stuck waiting for something until it times out - I just can't figure out what, or why it doesn't do it every time!

What is the status of KDE applications in htop? Are they shown as S, R or D?

Thanks bcooksley, and sorry it took me a few days. Looks like S and variants:

Code: Select all

Ss   //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
S    /usr/lib/kde4/libexec/start_kdeinit +kcminit_startup
Ss   kdeinit4: kdeinit4 Running...                 
S    kdeinit4: klauncher [kdeinit] --fd=9           
Sl   kdeinit4: kded4 [kdeinit]                     
S    /usr/bin/kglobalaccel
S    /usr/bin/kwalletd
Sl   kdeinit4: kcminit_startup [kdeinit]           
S    kwrapper4 ksmserver
Sl   kdeinit4: ksmserver [kdeinit]                 
Sl   kwin -session 10e2697461000131343159300000125960000_1314488987_811416
S    /usr/bin/kactivitymanagerd
Sl   /usr/bin/knotify4
Sl   /usr/bin/plasma-desktop
S    ksysguardd
S    /usr/bin/kuiserver
Sl   /usr/bin/akonadi_control
Sl   akonadiserver
Sl   kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-tuser/klauncherMT7033.slave-socket local:/tmp/ksocket-tuser/plasma-desktopGz7065.slave-socket
S    kdeinit4: kio_desktop [kdeinit] desktop local:/tmp/ksocket-tuser/klauncherMT7033.slave-socket local:/tmp/ksocket-tuser/plasma-desktopxe7065.slave-socket
Sl   /usr/sbin/mysqld --defaults-file=/home/tuser/.local/share/akonadi//mysql.conf --datadir=/home/tuser/.local/share/akonadi/db_data/ --socket=/home/tuser/.local/share/akonadi/socket-mybox/mysql.socket
S    kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-tuser/klauncherMT7033.slave-socket local:/tmp/ksocket-tuser/kio_desktopnn7082.slave-socket
S    /usr/bin/kaccess
Sl   /usr/bin/krunner
Sl   kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-tuser/klauncherMT7033.slave-socket local:/tmp/ksocket-tuser/krunnerjd7107.slave-socket
S    /usr/bin/nepomukcontroller -session 10e2697461000131343159600000125960008_1314488987_779873
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_0
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_1
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_10
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_11
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_12
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_13
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_14
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_15
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_16
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_2
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_3
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_4
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_5
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_6
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_7
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_8
S    /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_9
S    /usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_0
S    /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent
Sl   /usr/bin/akonadi_nepomuk_contact_feeder --identifier akonadi_nepomuk_contact_feeder
Sl   /usr/bin/kmix -session 10e2697461000131343159600000125960013_1314488987_779996
S    /usr/bin/nepomukserver
S    /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1
S    /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1
S    /usr/bin/klipper
S    /usr/bin/klipper


As far as I can tell - this means that they are all sleeping - ie. not using the CPU as such, and they are not awaiting on IO.

The best way to track this I guess would be to enable all debug areas using "kdebugdialog" then tail the ~/.xsession-errors file - seeing which output comes out just prior and after it unfreezes.

I have the same problem.
I'm using openSUSE 11.4 + Tumbleweed + KDF (4.7.1 of this writing).
I *think* it's related to the network manager stuff.
I will try an experiment to find out.

Edit: the experiment was inconclusive, but I still think it's network management.

[The experiment involved disabling "NetworkManager user settings Service" in Service Manager but, apparently, this does not work.]