Plasma desktop won't properly start anymore - high CPU load

Hi Guys,

I’ve got a serious problem over here, and I have no idea what triggered it, because I have not changed anything to my configuration, nor have I installed anything. But as it is, my system was working fine until yesterday.

Then I rebooted in order to test the new live ISO of another (and to myself befriended) distribution, and that went well too. But when I then rebooted into Manjaro again — which is my only installed system — things went really strange.

I had already noticed — and other Plasma users with me — that Plasma sometimes gets stuck if one logs in too quickly, in which case only one of my two panels is loading, but it is completely transparent and empty. The desktop also does not respond to right-clicking. Triggering a logout via Ctrl+Alt+Del does bring up the logout dialog, but whichever option you click has no effect — Plasma just stays stuck.

Yakuake — which is started automatically at login — does work, and with a delay, so does the KRunner. As such I was able to start KSysGuard, and it shows the plasmashell process stuck at 17% load.

The CPU temperature is also very high, and even though recent kernels have a bug that causes one core to max out at 100% I/O wait, this was not affecting the CPU temperature so far, but now the temperature reads around 60°C, and especially so on the stuck core. The other cores now hover between 45°C and 52°C. The normal average CPU temperature for this machine is 36°C.

I’ve already tried loads of things, from various commands to try and restart plasmashell — which yields all kinds of weird errors regarding cyclic dependencies, etc. — over several reboots, to even trying an older kernel, which (presumably) did not have the patch yet that caused the high I/O wait. But it’s no use. The result is always the same. Plasma itself is stuck and refuses to properly initialize.

Desktop shortcut keys do work, as does virtual desktop switching and activity switching, although my second activity shows the same wallpaper as my main activity, and that’s not correct either. But like I said, the top panel is completely transparent — it’s not even blurred, as it should be — and it’s empty, while the lower panel — which I’ve pretty much set up as a dock and which houses the activity and desktop pagers — is absent.

I repeat that everything was working perfectly fine up until yesterday — well, barring that high I/O wait, but that was mostly a cosmetic bug. But now something really is hogging my CPU, because the temperature on that core is way too high, and like I said, plasmashell shows as running at a constant 17% CPU load — this is a 6-core Intel i5, so that 17% total load would then indeed be consistent with the maxed-out CPU core.

I really don’t know what to do anymore guys. I’ve been exclusively running GNU/Linux for 24 years on servers and workstations, so I’m no rookie, but I’m at the end of my rope here. Like I said, I have changed nothing to my configuration — well, except for the colors of the CPU sensors in a panel widget — and everything was running fine earlier. The live ISO of the other distribution also ran perfectly fine, and it uses the same Plasma release as we have here in Manjaro Stable.

The only thing I can think of that has changed since the Stable update of 23.07.27 was that there have been updates to manjaro-zsh-settings and spectre-meltdown-checker, but I doubt that either of those two packages would have triggered this situation, and I’m pretty sure there aren’t any problems with my hardware either.

All of my relevant info can be gleaned from clicking my avatar, but I’ll briefly reiterate below…

Operating System: Manjaro Linux 
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.1.41-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 6 × Intel® Core™ i5-8400 CPU @ 2.80GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 630
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7C09
System Version: 1.0

I havent noticed this … and there is no open bug for it as far as I know.

Maybe stating the obvious … but … have you tried with a new user? Just to check it out.

1 Like

Not yet, but that’s next on my list of things to try.

The strangeness is in how and why this is suddenly happening, when everything was fine before and nothing was changed to the configuration.

Have you checked # journalctl -xe | grep plasmashell? It may scream for help. You might also want to check your drives’ health, as a sudden high CPU usage is commonly associated with a failing drive: a process keeps waiting for data to read/write, but it regularly fails.

1 Like

8 posts were split to a new topic: Akonadi causes high CPU load

Sorry guys, but that was a clear thread hijack. :frowning_man:

Others have reported the same, though. I’m not sure on where and when anymore, but my advice at the time — which worked for myself — was to delay the login at the SDDM screen a bit, giving the system time to initialize all of the background stuff first, because I presume(d) that it was a race condition.

Alas, things have taken on surreal proportions in the meantime — read on — so I don’t even know what to think anymore. :exploding_head:

I’ve now done that. And the new user had no problems whatsoever. Not even after I started applying some of my own theming, which — it needs to be said — cannot have been the cause of my problems, because it had worked just fine until I checked out the PCLinuxOS live image, which itself could not have had any effect on my installed system either, because nothing on-disk was mounted during that test.

But so anyway, yes, I created a new user, applied the same theming as I had in my main account, logged out a few times, logged back in, still no problems with the test account, although logging into my regular account still showed the same symptoms. The test account didn’t even have the high I/O wait problem, but that was probably because KMail and KOrganizer had not been set up yet.

Oh, wait, there was one little issue with the test account, but that may have been a glitch. When I brought up Dolphin, it did not show the application menu in the global menu widget in my top panel. Quitting Dolphin and restarting it fixed that, but it’s strange nevertheless. I’ve had issues with the application’s menu not showing up in the global menu widget before, but that was only with GTK applications, and it would remedy itself by switching over to a running Qt/KDE application and back, although after the 23.07.27 update, that appeared to have been fixed.

I am currently running off the live USB, by the way, because I’ve been seriously reconsidering a fresh installation.

I though about whether it could be a hardware problem, but the smartctl info on my SSD showed that it was still in perfect health, and like I said, the test account worked fine, albeit that some things — like the dialog for setting the wallpaper — were very slow to load.

Well, from the affected user you could:

cd ~/.config
for j in plasma*; do mv -- "$j" "${j%}.bak"; done
rm Trolltech.conf
kbuildsycoca5 --noincremental
cd ..

(of course this will wipe out your configurations … but may also wipe out your woes)

1 Like

Might it be worth the effort to compile sql from the AUR in order to avoid the mariadb issue? And if so, is it a drop-in replacement or am I going to have to start all over again with my KMail setup? :thinking:

I dont know if it is the same problem.
But if you want to look at the possibility of replacing mariadb … the archwiki seems to indicate it is possible. But I dont know why you must use sql
postegresql is in the repos and seems to be a sort of defacto implementation:
https://userbase.kde.org/Akonadi#How_to_upgrade_my_PostgreSQL_database
https://userbase.kde.org/Akonadi/Postgres_update

Archwiki and elsewhere also make reference to others like sqlite.
(which I happen to have installed as a dep for lots of KDE, while not using PIM/Akonadi at all)
https://wiki.archlinux.org/title/KDE#Akonadi

1 Like

KMail requires it, and I think it doesn’t support sqlite anymore.

I only see kmail depending on some akonadi and pim packages … which I would assume is the reason for the ‘depend’ … and so may similarly be functional with whatever can operate akonadi … in this case posteegresql seems like a likely choice.
But IANAA. (I am not an akonadi-user) :sweat_smile:

1 Like

Still, I would like to know why everything worked fine up until Monday, and why it suddenly won’t work at all anymore now, even though nothing had changed to my settings.

Finding the root cause of the problem should be the goal for fixing what went wrong without having to nuke everything related to Plasma in my main account. :frowning_face:

I guess you have no timeshift backup from the time before the issue occurred?

1 Like

As the matter of fact, I think I do, but given that I hadn’t changed anything to my settings and hadn’t installed anything, I considered it pointless to try that.

I’ll look into it right away. :slight_smile: :+1:

If nothing else, it should possibly show you the cause if updating again…

1 Like

Well, I’ve restored only my $HOME from the backup, but it’s no use. It’s still the same thing. So whatever the cause may be, it must be something from outside of my home directory. :frowning_man:


Well, if you can make sense of that, I cannot, and like I said, I hadn’t changed anything in my $HOME.

[nx-74205:/dev/pts/1][/home/aragorn]
[aragorn] >   journalctl -xe | grep plasmashell
Aug 02 11:10:41 nx-74205 plasmashell[2019]: Checking screens: available: (QScreen(0x55b0ce368300, name="DP-1")) redundant: QHash() fake: QSet() all: (QScreen(0x55b0ce368300, name="DP-1"))
Aug 02 11:10:41 nx-74205 plasmashell[2019]: Checking screens: available: (QScreen(0x55b0ce368300, name="DP-1")) redundant: QHash() fake: QSet() all: (QScreen(0x55b0ce368300, name="DP-1"))
Aug 02 11:10:41 nx-74205 dbus-daemon[1903]: [session uid=1000 pid=1903] Activating via systemd: service name='org.kde.ActivityManager' unit='plasma-kactivitymanagerd.service' requested by ':1.17' (uid=1000 pid=2019 comm="/usr/bin/plasmashell --no-respawn")
Aug 02 11:10:41 nx-74205 plasmashell[2019]: Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.
Aug 02 11:10:41 nx-74205 plasmashell[2019]: If this Plasma has been installed into a custom prefix, verify that its D-Bus services dir is known to the system for the daemon to be activatable.
Aug 02 11:10:41 nx-74205 plasmashell[2019]: Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.
Aug 02 11:10:41 nx-74205 plasmashell[2019]: If this Plasma has been installed into a custom prefix, verify that its D-Bus services dir is known to the system for the daemon to be activatable.
Aug 02 11:10:41 nx-74205 plasmashell[2019]: kf.plasma.quick: Applet preload policy set to 1
Aug 02 11:10:41 nx-74205 dbus-daemon[1903]: [session uid=1000 pid=1903] Activating via systemd: service name='org.kde.ksystemstats' unit='plasma-ksystemstats.service' requested by ':1.17' (uid=1000 pid=2019 comm="/usr/bin/plasmashell --no-respawn")
Aug 02 11:10:42 nx-74205 plasmashell[2019]: Cyclic dependency detected between "file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml" and "file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/ThumbnailStrip.qml"
Aug 02 11:10:42 nx-74205 plasmashell[2019]: Cyclic dependency detected between "file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml" and "file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationHeader.qml"
Aug 02 11:10:42 nx-74205 plasmashell[2019]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml:407: TypeError: Cannot read property 'Window' of null
Aug 02 11:10:42 nx-74205 plasmashell[2019]: file:///usr/share/plasma/plasmoids/org.kde.plasma.systemmonitor/contents/ui/main.qml:43:5: QML MouseArea: Cannot anchor to an item that isn't a parent or sibling.
Aug 02 11:10:42 nx-74205 plasmashell[2019]: file:///usr/share/plasma/plasmoids/org.kde.plasma.systemmonitor/contents/ui/main.qml:43:5: QML MouseArea: Cannot anchor to an item that isn't a parent or sibling.
Aug 02 11:10:43 nx-74205 plasmashell[2019]: qt.svg: link #g14830 is undefined!
Aug 02 11:10:43 nx-74205 plasmashell[2019]: qt.svg: link #g14830 is undefined!
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///home/aragorn/.local/share/plasma/plasmoids/org.kde.plasma.volumewin7mixer/contents/ui/MediaController.qml:202:4: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///home/aragorn/.local/share/plasma/plasmoids/org.kde.plasma.volumewin7mixer/contents/ui/InputManager.qml:6:2: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///home/aragorn/.local/share/plasma/plasmoids/org.kde.plasma.volumewin7mixer/contents/ui/DynamicFilterModel.qml:30:34: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///home/aragorn/.local/share/plasma/plasmoids/org.kde.plasma.volumewin7mixer/contents/ui/DynamicFilterModel.qml:30:34: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///home/aragorn/.local/share/plasma/plasmoids/org.kde.plasma.volumewin7mixer/contents/ui/DynamicFilterModel.qml:30:34: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///home/aragorn/.local/share/plasma/plasmoids/org.kde.plasma.volumewin7mixer/contents/ui/DynamicFilterModel.qml:30:34: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///home/aragorn/.local/share/plasma/plasmoids/org.kde.plasma.volumewin7mixer/contents/ui/DynamicFilterModel.qml:30:34: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///home/aragorn/.local/share/plasma/plasmoids/org.kde.plasma.volumewin7mixer/contents/ui/Mpris2DataSource.qml:159:31: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:47: TypeError: Cannot read property 'location' of null
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:48: TypeError: Cannot read property 'location' of null
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:49: TypeError: Cannot read property 'location' of null
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:46: TypeError: Cannot read property 'location' of null
Aug 02 11:10:43 nx-74205 plasmashell[2019]: qt.svg: <input>:65:6: Could not resolve property: #b
Aug 02 11:10:43 nx-74205 plasmashell[2019]: qt.svg: <input>:65:6: Could not resolve property: #c
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml:301: TypeError: Cannot read property 'Window' of null (exception occurred during delayed function evaluation)
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///usr/lib/qt/qml/org/kde/plasma/extras/PlaceholderMessage.qml:238:5: QML Heading: Binding loop detected for property "verticalAlignment"
Aug 02 11:10:43 nx-74205 plasmashell[2019]: qml: PlasmaExtras.ScrollArea is deprecated. Use PlasmaComponents3.ScrollView instead.
Aug 02 11:10:43 nx-74205 plasmashell[2019]: file:///usr/lib/qt/qml/org/kde/plasma/extras/PlaceholderMessage.qml:238:5: QML Heading: Binding loop detected for property "verticalAlignment"


I’ve also already run a consistency check on my akonadi data, and it gave me a healthy report, so it’s not that either. KMail also works perfectly fine.

:man_shrugging:


My CPU temperature is going sky-high again, so I’m going to switch back to my other account for now…

:frowning_man:

I have just checked, my output does not have this:

Aug 02 11:10:41 nx-74205 plasmashell[2019]: Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.

And according to this:

Found a solution which said to remove kactivitymanagerd folder.

rm -rf .local/share/kactivitymanagerd 

So mods you can close the thread now, ty.

So, you could try that…

1 Like

I will try that this evening — thank you. I’m going to go to bed now, because I’ve been up all night and it’s closing in on noon over here right now.

:woozy_face: :disappointed:

1 Like

I very much doubt that the mariadb issue is anything to do with your problem. Every report I’ve seen indicates that this is purely a cosmetic reporting issue and doesn’t lead to a rise in cpu temperature like real cpu load would. I’m running mariadb myself all day every day and my cpu temp right now is 35C which is idle temp.

kactivitymanagerd seems like a good lead. There are reports of it going berserk, seems to be related to it’s (sqlite) database becoming corrupted for unknown reasons. You can try either deleting the whole ~/.local/share/kactivitymanagerd/ folder as suggested above or just ~/.local/share/kactivitymanagerd/resources/ as in this post.

1 Like

Then it is likely not kmanagerd.

sqlite? the binary contains a lot of quirks but if a process has gone rogue and hammered the deb file - it is possible the database is damaged.

But I am :confused: about the about the fact that nothing was changed.

My apology - I missed this in the descriptions

It was as understand - a temporary start of an USB based system - and a subseqent restart after testing was done.

I assume you can get into a TTY or a live system.

There was a recent mitigation added - but that was for AMD - so likely not the issue.
I don’t really know why I am suggesting this - perhaps the mention of spectre-meltdown-checker - what if you boot to the grub menu - then edit and add mitigations=off to kernel command line?

So - although you have restored your home without success - it is an issue with a Plasma service.

You already mentioned plasmashell as the likely offender - so perhaps going over the relevant rc files in .config will reveal a damaged file?

My old friend Midnight Commander has sometimes helped me deduct whether a configuration file was corrupted.

Perhaps checking the log would clarify that …

1 Like