Plasma takes over a minute to load

When logging in, plasmashell takes about 70-80 seconds to load. During this time, xorg and kglobalaccell take a combined 100% of a cpu for the first half, and then xorg takes about 30% of cpu for the second half. Once plasmashell appears, everything is a bit sluggish for another minute or so. After this, everything is snappy and fast.
I am on new SSD’s, and nmon and my drive LED show basically no activity during the minute of waiting. Here is an approximate timeline from one I watched with an external clock:

  • 0s Press enter in sddm
  • 2s splash screen appears
  • 5s splash screen disappears
  • 6s all old windows from last session appear. I can interact with them, but they are a bit laggy
  • 70s plasmashell and desktop icons appear, any switch workspace keys I pressed before this point are applied now
  • ~120s Lag free

This is repeatable even when I don’t reboot, but simply log out, then log back in again, which gets rid of most of systemd being the issue, I think.

I’m fairly certain that this is some setting or configuration I changed, because when I installed this OS, it used to show up quickly, until I rebooted after I went through and changed a bunch of settings. How can I figure out what setting/configuration is causing this very slow load?

Try to check with systemd-analyze blame

It has no idea, and thinks nothing is amiss. I will update the question though, because on log out-log in it still does this, nothing boot related

edit: for reference: 10.843s (kernel) + 14.524s (userspace)

Which distri are you using, Neon?

A fresh install of Debian 12. I did notice that adding some type of system monitor (cpu?) basically crashed plasma with 100% cpu usage and had to reset early on, but that is long gone

Perhaps you should change your System Settings and afterwards start one time with an empty session.
And only the next time set System Settings to restore the session again…

Hmm… how would go about doing that? I changed a lot of settings (keyboard shortcuts, mouse behavior, window behavior, etc) and don’t want to loose that

System SettingsStartup and ShutdownDesktop Settings → “When logging in” choose “Start with an empty session” → press Apply
Afterwards restart or at least log out.

PS: This setting has nothing to do at all with any of the other settings you mentioned, like for the mouse, keyboard shortcuts etc.

Ah! Ok, I get what you are saying now.
I had actually grown tired of restoring a session, as it was launching applications without command line arguments, so I had switched to always start with an empty session. Does mean I can’t check the cpu usage anymore, but it still does this with a fresh session each time

Did you already try if this also happens in another (new) user account?

Did you already test your drives’ integrity?

And if this also happens when booted from a live USB session/other distribution with KDE Plasma, it could be a good idea to also thoroughly test your memory (e.g. with Memtest86+)…

Otherwise something like Baloo comes to mind - but I am really guessing now.

New user account? Instant
Live CD? Instant
My user account before I started tweaking: Instant

Drives are fine, nothing is using disk io, or waiting on disk in D state. It is xorg and kglobalaccel taking all the CPU usage

Then you already know where to look.
And only you know what you have done in detail, so retrace the steps…


That suggests ~/.config/kglobalshortcutsrc might be messed up. I suggest having a look at it; on my Kubuntu 23.10 desktop it has 385 lines. I’ve had to reset it in the past, my renaming it and logging out and in.

1 Like

@jlittle Thanks for the suggestion, but moving that file out of the way to use the defaults still results in the same 1 minute delay.

I did find this, but it’s not quite what I’m doing: 306352 – 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel

Some more observations: it takes 40 seconds for a global keyboard short to register, and desktop widgets are misplaced until the 1 minute mark is up.

journalctl shows stuff is happening, albeit slowly, but nothing about timeouts or delays.

Should I file a new bug?

How would it be a bug if YOU made changes that broke the system?

Your computer works with a live usb, that means there is something on YOUR system, not a bug.

It could be a swap thing, if for some reason your memory gets filled, your system would start to put all data into a swapfile or partition and THAT would obv slow down the startup.

Uninstall applications you have installed and change back the settings you made and see if you that fixes it, otherwise it might be time for a reinstall.

1 Like

Because I put it into an unusual configuration that was buggy? Many bugs require some nonstandard configuration to trigger, and “eats cpu for 1 minute while doing nothing” certainly sounds like it could plausibly be a bug.

To me, a KDE novice, KDE settings are opaque, and I don’t know where to look to either save them, or revert them. That’s really what I’m looking for in this thread: knowledge on how to save and selectively revert stuff to find the cause of this delay

A good though, but alas it isn’t that easy, I have 256GB of RAM, and I boot up with < 10% used.

So you uninstalled whatever this software was correctly and made sure everything went back exactly like it was before?
Potential changes in config files etc?

If you want to see system usage, a console and typing htop usually works very well. No need for any gui tools.

You can make a backup of your ~/home, that is where all those files reside. Then just copy them back after installation (not sure if you can keep your home intact with a reinstall of debian, someone correct me if I am wrong).

You can also save most settings, f.ex in the settings for shortcuts, you can press “Export Scheme” and save the file somewhere. Then after reinstall you can press “Import Scheme” to restore.

If you have ONLY changed settings in gui and not manually in any file, yes, it would be a bug.
But for you to make a proper bug report you have to reinstall (to be 100% sure there is not another application or setting interfering, correct kernel etc) and then be able to show exactly what you do to reproduce the bug.
Can you do that?

I love htop, but I also like having a cpu indicator on my toolbar. Previously, I dragged an “Individual core usage” or “memory usage” widget onto the toolbar and that was what caused the previous issue.

My /home is already on a separate partition, so yes. I don’t think the installer automates it, but easy enough to fix up fstab

That is my hunch

I spent all day installing nixos and then bisecting which kernel version introduced a device mapper bug, so I’m gong to say probably :slightly_smiling_face:. It will take me a couple days though, as I need to get some actual work done first

I edited my response to add this, you might have missed it so I quote myself.
About backing up your settings…

Because if you want to make a bug report, it would be way better if you slowly implement your settings back one by one rather than just change your home in fstab.
It would also identify exactly what it is that is creating “the bug”.

I have the same problem. Neon testing edition.