When KDE ( 4.9.4 ) starts it goes through the login splash screen and then presents the desktop.
Then for the next 20 seconds or so the desktop stops. What is it doing during this time ?
It is frustrating to the users, so I thought I'd do a little python script that counts down
from 100 to 0 in 30 seconds to let KDE get's it's act together and give some user feedback
so they don't think the system has hung. I put my script in Autostart but the problem is
whatever KDE is doing in that pause for 20 seconds or so is before Autostart is run.
So the question is
1 What causes KDE to become unresponsive for 20--30 seconds during login and
2 When can I put my script so that it get executed before that pause

Ta

Mal

Which applets do you have on your desktops by default?
This very much sounds like a applet is being naughty and performing tasks in a sync (blocking) manner rather than using async (non-blocking) methods.

My guess is that Plasma has not finished initializing completely when the freeze occurs - so the next phase of KDE startup - to run the autostart programs - is not triggered.

Unfortunately the only thing which runs before Autostart is the "Environment setup" - which is extremely early in the KDE startup process (even D-Bus is unavailable).

Only the default stuff that opensuse install.

Interestingly if you click on something ( firefox or dolphin for example, since they are on the panel in opensuse )
as soon as the desktop appears it responds and the program starts. If you wait a second or so it doesn't and
you have to wait a further 20-30 seconds until the desktop responds again. If you have speakers or headphones
the kde start jingle takes a while to happen. I was wondering if it relates to the fact that we use the same image
for all machines even if they have slightly different sound chips. I posted a question about this about a year
ago ( doesn't time fly ) and you suggested deleting ~/.kde4/share/config/phonondevicesrc on login which
solves the issue of kde asking users to forget sound setups when they go from one type of machine to
another. Could it be that kde is farting around looking for sound devices during this time?

Regards

Mal

The 20-30 second delay in responding likely indicates that the system is waiting for something to respond over D-Bus. This is highly unusual for Plasma - as all well written applets should be doing things in a manner which is non-blocking.

Are you using any non-default applets?

It's basically 'out of the box' openSuse
The only thing is users have nfs homes
but that's not exactly unheard of is it

Happy 2013

Mal

NFS Homes may explain part of it... are Akonadi and Nepomuk disabled/suppressed?

Yes, they are both off

Mal

Would it be possible for you to attach a debugger to plasma-desktop once it has "hung" (using an virtual terminal for instance) and to generate a backtrace?

Given that the time is ~30 seconds this is very likely to be a D-Bus timeout, but determining the actual call at fault will be fairly difficult unfortunately.

Hi.
Sorry for my english...
I have Fedora 17 x86 with KDE 4.9.4.
I was about to start a new topic for this problem when I found this one.
In about 90% of the starts KDE freezes for about 20..30 sec.

bcooksley wrote:Would it be possible for you to attach a debugger to plasma-desktop once it has "hung" (using an virtual terminal for instance) and to generate a backtrace?

I wanna try this but I'm a newbie in Linux so could you please explain how can I do it..?

Glad you asked, as I don't know either

Mal

The appropriate debugger to use in this case is 'gdb'. You may need to install it first. Next you need to make sure you have the appropriate debugging symbols for Plasma, kdelibs and Qt installed.

Finally, you are ready to start. gdb can be attached to a running Plasma instance by executing "gdb -p <pid of plasma-desktop>" where you need to replace "<pid of plasma-desktop>" with the appropriate number. You can discover this by running "pidof plasma-desktop".

Once it has attached itself, you can enter "thread apply all bt full" to get a full backtrace, and "exit" to quit out of gdb and allow plasma-desktop to continue execution.

Note: once you have attached gdb, it will suspend the execution of plasma-desktop - which will freeze the startup process of KDE.