You are not logged in.
Hey, I've been having the problem with Arch and KDE for a few weeks that when I want to turn off or restart my PC, my screen freezes and only after ~40 seconds the PC quits/restarts.
If I log out before shutting down/restarting, it is normally fast.
With “journalctl -b -1” I was able to find out that the time is lost when the “plasma-plasmashell.service” is terminated (but not 100% sure about this).
Apr 20 21:20:08 Threepwood systemd[1]: coolercontrold.service: Consumed 9.849s CPU time, 76.1M memory peak.
Apr 20 21:20:48 Threepwood systemd[898]: plasma-plasmashell.service: State 'stop-sigterm' timed out. Killing.
....
Apr 20 21:20:48 Threepwood systemd[898]: plasma-plasmashell.service: Failed with result 'timeout'.Furthermore I could find out that if I delete the KDE desktop settings “plasma-org.kde.plasma.desktop-appletsrc”, reboot once (takes a long time again), then the next reboot is fast but only this one , the next reboot is slow again (without changing anything on the system).
I've been searching for a while but haven't found a solution yet, except that I might kill the “plasma-plasmashell.service” on shutdown but I don't find that a particularly good solution, does anyone have an idea how I can fix this?
AMD Ryzen 7 9800X3D @ 5.22 GHz
NVIDIA GeForce RTX 5080
nvidia (open source) 570.133.07
Arch Linux Kernel 6.14.3-arch1-1
KWin (Wayland)
Last edited by HelmchenLord (2025-07-08 09:06:53)
Offline
plasmashell doesn't die on a sigterm and it seems to hinge on some plasma desktop widget thingy.
Does plasma-org.kde.plasma.desktop-appletsrc get recreated? What does it look like?
Offline
Yes, the plasma-org.kde.plasma.desktop-appletsrc is created again after logging in.
Here is my current plasma-org.kde.plasma.desktop-appletsrc: https://paste.c-net.org/BanjoCasinos
Offline
Image=/media/Data/Daten/Wallpaper/abstract_low_poly_plexus_design_background_2303.jpgI assume /media/Data/Daten isn't on the root or /home partition? What if you use a wallpaper from /usr/share/wallpapers ? (You can jsut copy this one there)
* plugin=org.kde.plasma.devicenotifier
* plugin=org.kde.plasma.cameraindicator
* plugin=org.kde.plasma.vault
These I could imagine causing trouble as well
Offline
By deleting the plasma-org.kde.plasma.desktop-appletsrc, the background image is also reset to the default, I don't think that can be the problem.
I would say these plugins are included by default, should I remove them? If so, I could not find out how to do it.
Offline
So this has happened w/o altering the defaults at all?
Is the workaround reproducible?
If so, can you reboot fast multiple times if everytime after the login you do absolutely nothing but immediately reboot again?
Also post the journal for a boot w/ a slow reboot/shutdown - the system default timeout is 90s and maybe something acts up before to explain why plasmashell doesn't terminate. Or maybe there's a crash before and the process restarts and therefore doesn't terminate.
We'll see… hopefully.
Offline
It seems that it was just a coincidence with deleting the plasma-org.kde.plasma.desktop-appletsrc, this time it didn't help.
If I restart several times without doing anything, it is usually slow and rarely fast.
But I had two quick reboots without doing anything different than usual.
Here is the output from "sudo journalctl -b -1" of the slow reboot: https://paste.c-net.org/RussoEyesight
And here from the fast one: https://paste.c-net.org/RemorayProtests
Offline
Bad:
Apr 25 18:12:55 Threepwood systemd[902]: Stopped PipeWire Multimedia Service.
Apr 25 18:12:55 Threepwood kwin_wayland[980]: kwin_screencast: PipeWire remote error: connection error
Apr 25 18:13:35 Threepwood systemd[902]: Closed PipeWire PulseAudio.
…
Apr 25 18:13:35 Threepwood systemd[902]: plasma-plasmashell.service: State 'stop-sigterm' timed out. Killing.
Apr 25 18:13:35 Threepwood systemd[902]: plasma-plasmashell.service: Killing process 1096 (plasmashell) with signal SIGKILL.
Apr 25 18:13:35 Threepwood systemd[902]: plasma-plasmashell.service: Killing process 1255 (n/a) with signal SIGKILL.
Apr 25 18:13:35 Threepwood systemd[902]: plasma-plasmashell.service: Killing process 1260 (n/a) with signal SIGKILL.
Apr 25 18:13:35 Threepwood systemd[902]: plasma-plasmashell.service: Killing process 1293 (n/a) with signal SIGKILL.
Apr 25 18:13:35 Threepwood systemd[902]: plasma-plasmashell.service: Killing process 1307 (KIO::WorkerThre) with signal SIGKILL.
Apr 25 18:13:35 Threepwood systemd[902]: plasma-plasmashell.service: Main process exited, code=killed, status=9/KILL
Apr 25 18:13:35 Threepwood systemd[902]: plasma-plasmashell.service: Failed with result 'timeout'.Good:
Apr 25 18:10:09 Threepwood systemd[905]: Stopped PipeWire Multimedia Service.
Apr 25 18:10:09 Threepwood systemd[905]: pipewire.service: Consumed 1.470s CPU time, 12.5M memory peak.
Apr 25 18:10:09 Threepwood kwin_wayland[992]: kwin_screencast: PipeWire remote error: connection error
Apr 25 18:10:09 Threepwood kwin_wayland[992]: kwin_wayland_drm: atomic commit failed: Keine Berechtigung
Apr 25 18:10:09 Threepwood plasmashell[1147]: file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/items/PlasmoidItem.qml:24: TypeError: Cannot read property 'toolTipMainText' of null
Apr 25 18:10:09 Threepwood plasmashell[1147]: file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/items/PlasmoidItem.qml:24: TypeError: Cannot read property 'toolTipMainText' of null
Apr 25 18:10:09 Threepwood plasmashell[1147]: kpipewire_logging: PipeWire remote error: -32 connection error
Apr 25 18:10:09 Threepwood kded6[1133]: kf.notifications: Had queued notifications on destruction. Was the eventloop running?
Apr 25 18:10:09 Threepwood plasmashell[1147]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml:130: TypeError: Cannot read property 'screenGeometry' of null
Apr 25 18:10:09 Threepwood systemd[905]: Stopped KDE Daemon 6.Bad:
Apr 25 18:12:15 Threepwood plasmashell[1096]: error creating screencast "Could not find window id {2c1d236a-2c4b-4346-b5ea-5bc339d74328}"
Apr 25 18:12:31 Threepwood plasmashell[1096]: error creating screencast "Could not find window id {e993908b-7b37-4b8c-b179-382f70cedb4b}"
Apr 25 18:12:55 Threepwood kwin_wayland[980]: kwin_screencast: PipeWire remote error: connection error
Apr 25 18:12:55 Threepwood plasmashell[1096]: error creating screencast "Could not find window id {faf55b87-e06a-4120-a34e-91dd83dab376}"Good:
Apr 25 18:10:09 Threepwood kwin_wayland[992]: kwin_screencast: PipeWire remote error: connection errorAny idea what that is?
Offline
No idea what the screencast or PipeWire errors mean, couldn't find anything online that would have helped me.
The errors also appear in the log when the reboot is quick.
I also have a quick reboot log, which also contains the screencast and PipeWire errors: https://paste.c-net.org/SteppeMorose
Offline
Are you running a screencast?
Anyway w/ the other journal that's likely a red herring.
plasmashell is hanging in some kio worker thread, judging from https://bugs.kde.org/show_bug.cgi?id=499382 (not your bug, just a backtrace) likely some socket.
https://bbs.archlinux.org/viewtopic.php?id=297882 blames a bogus QT_QPA_PLATFORMTHEME environment
Ftr, https://www.reddit.com/r/archlinux/comm … ownrestart is you but https://www.reddit.com/r/kde/comments/1 … erm_timed/ seems a similar problem
Offline
No, I do not use Screencast.
I had already looked at the two links initially when looking for a solution.
I have not set QT_QPA_PLATFORMTHEME and kdeidletime5 is not running on my system, only kdeidletime6.
I had already seen the idea with the script and that would probably be a workaround but not a real solution to the problem.
If I can't find a solution, I would try the script but I'm not a big fan of that.
Offline
https://wiki.archlinux.org/title/Debugg … ng_process
https://wiki.archlinux.org/title/Debugg … _a_program (for logging, "thread apply all backtrace full"; continue)
Because of the relatively short stall you probably want to script that and "gdb -x your_script", make sure to not forget to open yama before initiating the shutdown and have a TTY shell open so you can timely intercept plasmashell when you notice it hanging.
"$(pidof plasmashell)" should help you to resolve that fast (perhaps put the entire gdb call into a shell script ~/bin/wtf or so)
Knowing "where" it's hanging out might hint to the "why"… ![]()
Offline
Unfortunately, I cannot switch to TTY with Ctrl+Alt+F3 (no matter which F key) when the system hangs.
The screen is frozen and nothing happens when I press Ctrl+Alt+F3 until the restart happens at some point.
Offline
According to the journal the network was still up when plasmashell got killed, can you ssh into the system and interact with it while the shutdown stalls?
Offline
Sadly, the SSH connection is closed before it hangs and cannot be reopened.
Maybe I should just reinstall the system...
Offline
It is not very likely that you can re-install yourself out of what seems to be a frequent plasma problem.
Do you use any remote filesystems? (nfs, cifs, smb, …)?
Offline
I have a one cifs (NAS) one vfat (boot) and 7 btrfs mounts in my fstab.
Edit: But the cif unmount is successfully performed before the plasma-plasmashell hangs.: "Unmounted /media/Midgard"
Last edited by HelmchenLord (2025-05-04 13:01:38)
Offline
Drop the CIFS mount, try again…
Offline
I have removed the cifs mount but the problem still occurs.
Offline
while true; do ps fhaux > ~/kiowhat.txt; sleep 1; doneYou cannot run that from within the plasma session you intent to shutdown from, but maybe running that on TTY3, returning to plasma and then rebooting will tell us what that stupid kio worker thread is.
Do you have any automounts in your fstab (which could get triggered during the shutdown, preventing it from happening)?
Offline
I don't have any automounts.
With the script running in the background, the problem behaves slightly differently. The screen doesn't hang completely instead the output is “The system is shutting down” (or something like that) and a blinking cursor, so it doesn't hang completely but still takes a long time.
Here is the log from the script: https://paste.c-net.org/TrappedPolly
And here is the log from journalctl: https://paste.c-net.org/CrippleWorker
I checked the output from the script but couldn't see anything unusual.
Offline
Ah, shit.
while true; do ps fhaux >> ~/kiowhat.txt; sleep 1; doneBut try to https://wiki.archlinux.org/title/Baloo# … he_indexer
Offline
Here is the output from:
while true; do ps fhaux >> ~/kiowhat.txt; sleep 1; donehttps://paste.c-net.org/FaucetGauze
And journalctl: https://paste.c-net.org/SmellHoward
After that I disabled baloo but no luck.
Offline
Now I have started seeing this as well.
I think there is something wrong. Probably a regression happened recently.
Offline
guybrush 4658 30.0 0.3 268878528 125596 ? DNsl 11:33 0:23 \_ /usr/lib/kf6/baloo_fileis the only uninterruptable process in that list,
guybrush 4968 0.0 0.0 268534236 24244 ? S 11:34 0:00 \_ /usr/lib/kf6/kioworker /usr/lib/qt6/plugins/kf6/kio/tags.so tags local:/run/user/1000/plasmashellaKGDgv.4.kioworker.socketis a baloo thing.
=> Double, triple and quadruple check that baloo isn't running anymore…
Offline