4

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...

Improve this question

3 Answers 3

Reset to default
6

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.

Improve this answer
1
  • 1
    For the record, Qubes 3.2 left KDE in favor of XFCE where this workaround is not available anymore. Completely disabling the compositing engine allows to reduce occurrences of this issue to a manageable ratio (around 2 times per month), and when it happens closing the lid to put the laptop into sleep mode and reopening it to wake it up two times in a row allows to reset the graphic card back into a usable state without loosing the work (on most cases even SSH manages to keep its connection alive).
    – WhiteWinterWolf
    Mar 22, 2017 at 9:59
1

I'd try installing Qubes R3.1. KDE message notifications do pop up with useful information e.g. USB detected, connected to network etc. With a more modern kernel (4.1.13-7) among other things, R3.1 seems cleaned up and works very well compared to previous releases. The desktop has only crashed once after using their experimental update but a notification box with an option to report did pop up.

Instead I took their advice to backup VMs and freshly install R3.1. Happy to report it's been a more pleasant and crash free experience (with better notification pop ups).

Improve this answer
3
  • Qubes KDE doc. Also have a look at Nalu’s KDE customization thread for some really kool ideas
    – rustynuts
    Jan 2, 2016 at 23:55
  • I've upvoted your answer since I guess / hope this will be the cleanest solution (making my question obsolete in some near future). However, I'm still waiting for 3.1 to be officially stable before migrating, and now I've found a working fix so I can continue to work serenely until then :).
    – WhiteWinterWolf
    Mar 10, 2016 at 14:52
  • It looks like you've nipped your problem, but 3.1 did become officially stable as of yesterday
    – rustynuts
    Mar 10, 2016 at 15:35
0

Upgrading to Qubes 3.2 using sudo qubes-dom0-update --releasever=3.2 as documented here will solve the problem.

You can then install KDE from Qubes repo.

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.