Last week I updated a Kubuntu 26.04 LTS workstation and came back to a broken desktop. KDE Plasma would start, the desktop would flash for a second, then disappear. plasmashell kept crashing in a loop. The machine was otherwise fine: Konsole worked, Firefox worked, Thunderbird worked, the system was responsive. Just no desktop.
This is what I found and how I fixed it permanently.
What was happening
The crash was a SIGSEGV in plasmashell, repeating every few seconds with Failed with result 'core-dump' in the service logs. After digging into the stack trace, the culprit was fontconfig.
The root cause is a race condition at login. When you log in after a system update that touches font packages, plasmashell starts reading the font cache at the same time something else triggers its regeneration. fontconfig ends up writing a new cache while plasmashell is already reading the old one, which causes a segfault inside FcCharSetHasChar.
It is a timing issue, which is why it does not happen on every update and why a simple restart sometimes appears to fix it temporarily.
Diagnosing
Before touching anything, confirm the crash is what I described:
coredumpctl list --since today --no-pager
You should see plasmashell crashes. Then read the stack:
coredumpctl info plasmashell --no-pager | grep -A40 "Stack trace of thread"
Look for FcCharSetHasChar in the trace. If it is there, you have the same issue.
Also worth checking the session log:
journalctl --user -b --no-pager -p warning | grep -iE "plasmashell|fontconfig" | tail -20
Temporary fix
This gets the desktop back immediately without a reboot:
rm -rf ~/.cache/fontconfig
sudo rm -rf /var/cache/fontconfig/*
sudo fc-cache -r -f
fc-cache -r -f
systemctl --user reset-failed plasma-plasmashell
systemctl --user restart plasma-plasmashell
The desktop should come back within a few seconds. This works until the next reboot, at which point the race condition can happen again.
Permanent fix
The real solution is to force a font cache regeneration before plasmashell starts. You do this with a systemd drop-in that adds an ExecStartPre directive to the plasmashell service:
mkdir -p ~/.config/systemd/user/plasma-plasmashell.service.d
Then create the drop-in file:
cat > ~/.config/systemd/user/plasma-plasmashell.service.d/fontcache.conf << 'EOF'
[Service]
ExecStartPre=/usr/bin/fc-cache -f
EOF
Reload systemd and reboot:
systemctl --user daemon-reload
sudo reboot
After login, verify it worked:
systemctl --user status plasma-plasmashell | head -10
You want to see this in the output:
Process: ExecStartPre=/usr/bin/fc-cache -f (code=exited, status=0/SUCCESS)
Active: active (running)
If you see that, the drop-in is working and the font cache is being regenerated before plasmashell touches it on every boot.
Why this works
The systemd drop-in ensures fc-cache completes before plasmashell starts. No race, no partial file reads, no segfault. It adds a second or two to login time, which is a reasonable trade for a stable desktop.
The drop-in survives updates because it lives in your user config directory, not in the system service file. If a future KDE or fontconfig update changes the timing behavior, you can simply remove the drop-in and check if the issue is gone.
Environment
Kubuntu 26.04 LTS, KDE Plasma 6.6.6, kernel 7.0.0-34, Intel Raptor Lake i915. I deploy Kubuntu 26.04 on client workstations and hit this after a routine update. The fix has held across multiple reboots and subsequent updates.
If you are seeing something similar but the stack trace does not mention fontconfig, this drop-in will not help. The crash is something else. Check the coredumpctl output carefully before applying anything.
Top comments (43)
i use arch btw 💀
Fair enough, you probably never see this kind of problem anyway.
I don't have the knowledge about you are explaining in this article. I'mt a noob user.
But in my case this happens to me after the update, but combinated with crhome v154 in Kubuntu 24.04
It's weird and i don't know how to explain it well, but i figure out this:
.. Ah and this not happens with chrome / chromium version 153 or don't open it
I hope this help to you
Thanks for sharing this. The Chrome v154 angle is interesting, it might be writing something to a shared config or font directory on first launch that triggers the same race condition at login. The fact that v153 works and v154 breaks is a useful clue. If you want to dig deeper, run coredumpctl info plasmashell after the crash and check if FcCharSetHasChar appears in the stack trace. That would tell you if it is the same root cause or something different.
Interesting, they point to google chrome as culprit.
I'm a firefox user but had been messing with chrome today and had the same problem.
Really glad it worked. The Chrome/Chromium connection is becoming clearer from these comments, Brave, Chrome, same Chromium base, same problem. It looks like v154 is writing something on first launch that triggers the fontconfig race condition. The fix works regardless of the trigger, but knowing the root cause helps. On the subreddit suggestion: good idea :)
I can confirm that Brave caused this problem for me on a new install of Kubuntu 26.04 and that the permanent fix above did the trick. I first had the problem with 24.04 which brought me here. I decided to go ahead with a fresh install of 26.04 instead of fixing 24.04. Everything was fine until I installed Brave. I rebooted before installing Brave and again after which is when plasma crashed.
Thanks for the tips, they are a life saver.
That is a clean reproduction actually. Fresh install, everything fine, Brave installed, reboot, crash. That pretty much confirms Brave as the trigger. Good that the fix held on 26.04 as well.
I forgot to add that I did install some extensions into Brave before rebooting ... Dark Reader and Group Speed Dial. Not impossible that they had an effect. I'm going to install 26.04 on my laptop too so I'll reboot before adding the extension on that.
Interesting detail. Extensions run their own install routines so it is possible one of them touched something in the font or config directory. Worth testing on the laptop with a clean reboot before and after extensions. If the crash happens without extensions installed, that narrows it down to Brave itself.
Thanks a lot for this excellent fix.
I had the same issue after an update of several apps on Kubuntu 26.04. I am not a specialist, but I am wondering about Google Chrome or KCalc as the origin of the problem. True, I also use Google Chrome 154 ( 154.0.8037.57) and there was a recent update. However, in my case, the plasmashell crash occurred after a KCalc crash (KDE's simple calculator). A crash message mentioned that KCalc had stopped working. I cleared (root) /var/crash and restarted the computer, and then the plasmashell crash happened for the first time. Again, this may have nothing to do with it and I am no specialist, but I have read on other forums that after a KCalc crash you precisely have to clear fontconfig by:
rm -rf ~/.cache/fontconfig/
Would the KCalc crash be a consequence of the Chrome fontconfig issue, or would it be the origin of the plasmashell crash?
Exactly right. Qt uses fontconfig under the hood for text rendering, which is why the crash spreads across KDE applications. Chromium writes something on first launch that corrupts the cache, and then anything built on Qt that tries to read it fails. The systemd drop-in fixes it by regenerating the cache before plasmashell loads.
My guess is that Chrome triggered the fontconfig corruption first, and the KCalc crash came after as a consequence. KCalc is a Qt application and Qt uses fontconfig for rendering, so once the cache is corrupted any Qt app can crash. partd's link explains it well. The clearing of fontconfig after the KCalc crash is what temporarily fixed things for you, which confirms the cache was the common cause.
You saved my day! Thanks!
This worked on this machine after upgrading and getting a crashing plasmashell:
OS: Kubuntu 26.04.1 LTS (Resolute Raccoon) x86_64
DE: KDE Plasma 6.6.6
GPU: Intel Graphics @ 2.50 GHz [Integrated]
CPU: Intel(R) Core(TM) Ultra 7 365 (8) @ 4.90 GHz
Theme: Breeze (Light) [Qt], Breeze [GTK2/3]
Kernel: Linux 7.0.0-34-generic
Host: 21V9S08K00 (ThinkPad X1 2-in-1 Gen 11)
Glad it worked on the X1! The plasmashell crash on 26.04 caught a few people off guard. Good specs by the way.
Thank you so much for this solution! Worked like a charm.
This happened after an update and restart today, and looking at my update history I see brave-browser on the list, and none of the other candidates seem like things that would have caused this kind of issue.
Brave makes total sense. It shares the same Chromium base as Chrome, so the same behavior on first launch. You are probably the third person today confirming that connection. Glad it worked.
After reading the comments, it is hard to believe this is just a Chromium/Chrome bug. Any application running under user permission could intentionally corrupt fontcache and crash Plamas. This could potentially expose to Local Code Execution. Someone from Plasma should have Vul bug opened and fix the issue, so Plasma can handle corrupted font cache file gracefully.
That is a fair point. The real fix should be in Plasma handling a corrupted or partially written font cache gracefully instead of segfaulting. The systemd drop-in is a workaround that prevents the race condition, not a solution to the underlying fragility. Worth opening a bug on the KDE tracker if it has not been done already.
Worked like a charm and saved me a reinstall. Many thanks.
Happy it saved the reinstall. That is exactly why I documented it, went through the same thing myself.
Hi everyone.
Thanks so much for this fix.
Kubuntu 26.04 with Chrome: Version 156.0.8078.47 (Official Build) (x86_64)
Is this now fixed with the latest version?
If so, how do we revert the fix and remove the code?
TIA
Hi Steve. The root cause here was Chrome/Chromium v154 writing something on first launch that corrupted the fontconfig cache. You are on v156, which is two versions past the confirmed trigger. The upstream Chromium bug has likely been fixed by now.
To test if you still need the drop-in, remove it and reboot:
bash
rm ~/.config/systemd/user/plasma-plasmashell.service.d/fontcache.conf
systemctl --user daemon-reload
sudo reboot
After rebooting check plasmashell is stable:
bash
systemctl --user status plasma-plasmashell | head -10
If it runs cleanly and the desktop holds across a few logins, you do not need the fix anymore. If the crash returns, put the file back and the drop-in takes ten seconds to restore.
Thanks for the prompt reply.
Here we are after 3 reboots. Looking good but better not speak too soon😉
systemctl --user status plasma-plasmashell | head -10That output is clean. No ExecStartPre line means the drop-in is gone, and plasmashell is running fine without it. Three reboots is a solid test. Looks like Chrome 156 no longer triggers the corruption. You are good :)
Thank you! This blog post brought my panel back on Kubuntu 24.04 x11! The panel just started disappearing a day ago. My system had been fine for a long time. I update regularly, but I don't know what caused the problem. Also, strange was that rollback to a chronshield snapshot from 2 weeks ago did not fix my problem, but your blog post did. Before I found this post, I used a chatbot to troubleshoot, and while it didn't mention this post, it seemed have a lot that was in the post--just not the solution to keep the problem from coming back. I wish I saw your post earlier. Thanks again!
Really glad it helped. The fact that a two week old snapshot did not fix it suggests the trigger was something that changed in the font cache or a shared config file that the snapshot did not capture, which makes sense with what others are reporting about Chromium v154. The persistent fix with the systemd drop-in is exactly the part that most troubleshooting guides miss. Thanks for the kind words.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.