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 (39)
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.
i use arch btw 💀
Fair enough, you probably never see this kind of problem anyway.
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.
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.
Thanks again.
The Kubuntu Focus Team considers this indeed as a Google Chrome bug:
"Although this issue is the responsibility of Google, the Kubuntu Focus Team have taken steps to monitor upcoming versions of Google Chrome to help identify and prevent distribution of a broken version like this in the future."
reddit.com/r/Kubuntu/comments/1wo8...
Good to know the Kubuntu Focus Team is on it. Makes sense that they treat it as a Chrome bug rather than a KDE or fontconfig bug. The cache corruption is triggered by Chrome, the fix should come from Chrome. Until then the drop-in keeps things stable.
Thanks a lot for this post! I ran into the exact same issue after the latest update and was going crazy digging through logs. The systemd drop-in fix is incredibly clean and works perfectly. Clear, concise, and straight to the point. Thanks for sharing! 🚀
Glad it helped. The logs are the right place to start but fontconfig issues are not always obvious from them. Happy it is sorted.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.