Fedora – How to enable Plasma/KDE automatic restart upon freeze

fedorafreezekdeopensuse

I used OpenSuse for several years now. One of the things I utmost liked with this distribution was the way Plasma/KDE issues where handled: from time to time it may happens that the panel briefly disappear and a messagebox opens-up telling me that Plasma desktop has crashed and has been restarted, also proposing to send debugging data to development teams if I like to.

Now for a few months I've switched to a Fedora-based distribution (Qubes OS, based on Fedora 20). It seems that this distribution does not offer this behavior by default, since:

  • I never saw this messagebox anymore,
  • But I got my desktop completely freezed several times (screen and keyboard frozen, sound and mouse pointer OK), having to brutally shut-down my computer, crossing my finger that loosing all ongoing work will be the only side-effect of such a brutal shutdown.

A dozen of years ago, when I was student, my University was also using Fedora for our hands-on exercices. At that time, facing similar freeze I found the solution to connect remotely through SSH and kill the desktop manager so it gets automatically restarted, unlocking the graphical environment.

Sadly, due to the specific design of Qubes OS¹, this quick-and-dirty SSH solution will not work here. However, I guess that OpenSuse's messagebox tool may do a similar thing in a proper way: implement some kind of watch dog detecting when Plasma/KDE does not respond, then kill and restart it.

So what I'm wondering is: is this tool a specific feature of OpenSUSE², or is there some package I should install or some configuration I should change to enable this behavior on my current installation?

Desktop freezes are particularly frustrating, even-more when I know that the application themselves are most probably still working fine and that a simple restart of the Plasma process would just get everything back to normal…

¹: In Qubes OS the network connectivity is isolated in a Xen domain and KDE is in a networkless Dom0. For security reasons, Qubes OS is precisely designed to avoid reaching the user interface from the network…

²: By the past (if it's not still the case) OpenSUSE used to have an internally heavily modified KDE, allowing them to be the first distribution to propose a stable KDE4, so I fear that this tool is just a part of these sweets…

Best Answer

TL;DR: Here the problem was apparently caused by an issue (most probably some obscure race condition) between OpenGL and KWin.

To workaround it, one must disable OpenGL and use XRender instead (in System configuration > Desktop effects > Advanced > Compositing type, select "XRender" instead of the default OpenGL).

A few desktop effects will not be available anymore, but at least the system will be stable and not freeze anymore.

Long story:

The issue occurred every few weeks randomly, some times several times a day, some times two or three weeks with no issue, and was therefore quite difficult to analyze (BTW at some point I switched to another video card, switching from radeon to Intel i915 without any impact on the issue, therefore it is related neither to the graphic card nor its driver).

I left a script running in the background and doing automatic checks every three minutes in an infinite loops so they could hopefully catch something when the desktop freeze.

Indeed, the freeze can be programmatically detected through qdbus, and in particular this call fails if and only if the desktop is frozen:

qdbus org.kde.Kwin /App org.freedesktop.DBus.Peer.Ping

While normally it has no output and a return code of 0, when the desktop is frozen this command fails with a return code 2 and a "NoReply" error message.

For information, I've also checked the status of org.kde.plasma-desktop, org.kde.kuiserver and org.kde.kded which all seem sane when a freeze occurs, therefore KWin seems the real culprit.

I tried several ways to restore the desktop environment integrity with no luck. Trying to restart KWin cleanly using kquitapp kwin or kwin --replace didn't seem to have any noticeable effect. I tried to kill and rebuild the complete desktop environment as follow:

kbuildsycoca4
kquitapp plasma-desktop
kquitapp kwin
kquitapp kuiserver
sleep 2
killall plasma-desktop kwin kuiserver; sleep 2
killall -9 plasma-desktop kwin kuiserver; sleep 2
kstart kuiserver
kstart kwin
kstart plasma-desktop

The desktop unfreezed itself! ... but only for one frame: the screen (as can be seen when looking at the clock in the taskbar) is updated and freezes immediately again.

Nevertheless, having found the culprit, I've found an old "high, critical but won't fix because too obscure" issue here. Same symptoms, same diagnostic steps, and finally this suggested workaround: use XRender instead of OpenGL.

It has been several months now since I applied this change and I encountered no freeze since then, so I think this workaround to be correct for this issue.

Related Question