kwin is unstable

English Applications
1

Hi, I’m using openSUSE 15.0 with KDE.

The application kget stopped responding, and I then gave the command

killall -9 kget

which caused several problems to the KDE dekstop: For example, the KDE panel disappeared, and running programmes wouldn’t terminate with [Ctrl] + Q. (Various crash messages appeared on the system tray, right before the panel disappeared.)

Then I logged in as root and opened Dolphin, and the following message appeared:

kwin is unstable.
It seems to have crashed several times in a row. You can select another window manager to run.

Any help with restoring kwin, and reverting the deleterious effects of the above command would be greatly appreciated. Thank you very much in advance!

2 
killall -9 kget

I haven’t checked to verify, but shouldn’t that be

killall kget

or

kill -9 [PID]

?

3

There’s no telling what processes you may have killed - have you tried a reboot?

4

I confirm the command shown is not what it should be. And … never log in on a desktop as root.

5

Thank you kerijan2003, tannington, Knurpht. I don’t know what the difference is, with or without -9, but I had just seen this disastrous

killall -9

somehwere, probably
https://www.linux.com/learn/intro-to-linux/2017/5/how-kill-process-command-line
or https://www.booleanworld.com/kill-process-linux/
So I just copied it thoughtlessly, having no idea it would somehow (how?) mess up kwin.

I clicked on Shut Down while logged in as root, but a black screen appeared and it failed to switch off. The mouse pointer is still there. Should I try any keyboard shortucts on the black screen before pressing the power button on the machine? Thanks again!

6

The man page does mention “-SIGNAL” as an option to “killall”.

On the other hand, I would avoid “-9” with “killall”.

7

Try to switch to a virtual terminal using CTRL-ALT-F2 then login as your normal user and execute:

sudo /sbin/shutdown -r now

If that fails, or you are unable to switch to a virtual terminal then try to close down gracefully using the “Magic Sys Request”, that is:

Press and hold the ALT + PrtScr/SysRQ key, then whilst keeping those two keys depressed, press the following keys in sequence: R, E, I, S, U, and B. Allow a few seconds between each key press.

If that fails, then you’ll have to either power off, or use the reset key on the PC.

8

Dear Tannington, thank you very much for your helpful answer! I fortunately didn’t have to use the magic SysRq key, but thanks for sharing this cool combination! I typed Ctrl + Alt + F2, logged in normally, entered

sudo /sbin/shutdown -r now

as you wrote, and then my computer restarted.

The panel is still missing, and a konsole window was opened automatically. Basic key combinations involving the Alt key (used to invoke the menu of the active window) do not work, nor does Alt + Tab (to see if there are any other windows open), nor Ctrl + + (which I use to increase the font size within konsole). And the konsole window appears without its borders (but Alt + F3 does not work to bring them back).

Now if only some venerable guru could spout a few lines that would magically troubleshoot and accordingly restore kwin to its pristinely functional state…

9

As a method of last resort, would booting from a snapshot, as described here,

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.snapper.html#sec.snapper.snapshot-boot

undo the damage caused by

killall -9 kget

? Thanks

10

Yes, I imagine that rolling back to (probably) the last snapshot would be the easiest option to restore a working machine. The desktop environment does appear to be rather broken at the moment.

I don’t have snapper enabled on any of my machines as I don’t use btrfs, so I’m unable to offer any advice in that respect. The documentation you linked to looks to explain the workings quite well, if you’re unsure of anything ask again and I’m sure others will offer assistance.

11
  1. Do you automatically login?
  2. Is a login to a VT possible?
  3. Does the KDE Display Manager (SDDM) appear?

[HR][/HR]It may be that, the default user’s KDE environment has been corrupted.

  • Check the contents of /tmp/.
  • Check the contents of /var/tmp/.
  • Check the contents of the user’s ~/.cache/ directory.

From a VT session, logged in as the user which is not behaving as expected, you can safely remove all the affected user’s files in the ‘tmp’ directories and, the contents of the affected user’s ‘~/.cache/’ directory.

You can also safely the remove the affected user’s ‘~/.Xauthority’ file – do not, never ever, attempt this while the user’s X11 session is running …

It may be that, “kget” has left some temporary files somewhere other than in the “tmp” directories or, the affected user’s ~/.cache/ directory – you’ll need to search …
Also, check if there’s a “kget” configuration file in the affected user’s ~/.config/ directory – either remove it or, check if “kget” is being started at the affected user’s login.

12

@morera:

You seem to have a Btrfs system partition:

  • With a VT session and the user “root”: execute “systemctl rescue” – at the message, type in the password of the user “root”.
  • At the command prompt:

[INDENT=2]btrfs balance start -dusage=85 /
btrfs balance start -musage=70 /
btrfs scrub start /[/INDENT]
Execute the commands one by one – wait until each command completes (will take some time) before executing the next command …
[HR][/HR]For the future, ensure that, the systemd services and timer services related to Btrfs maintenance are enabled and, occasionally check that the Btrfs maintenance has in fact been executed …

13

Maybe only your standard user is affected. A simple test is to add a new test user using YaST’s User and Group Management (which may be preferable to »useradd« in this case). Then log into KDE with that test user and check if everything works. If it does, then you could compare configs and logs with your standard user.

14

Thank you very much dcurtisfra, unix111, tannington! I really appreciate your kind and helpful responses. Rolling back to a snapshot did indeed stabilise KWin.

[HR][/HR]@dcurtisfra: Thank you for the specially detailed answer. I appreciated all the helpful suggestions and information, in particular about systemd, about which I plan to learn more. Unfortunately, I confess I read your answer after having rolled back to a snapshot. At least I checked in

/etc/sysconfig/btrfsmaintenance

that BTRFS_BALANCE_PERIOD is set to the default ‘weekly’.

[HR][/HR]
While booting from a few different read-only snapshots (in order to decide to which I should roll back), I noticed that KDE Desktop Effects such as zooming in (Meta + =) never worked (although Zoom had been enabled under KDE’s Desktop Behaviour).

After having rolled back to my chosen snapshot, I went to ‘Display and monitor’, then ‘Compositor’ and saw that ‘Enable compositor on startup’ had been unchecked: Evidently some protection function had been activated by the system. Here’s the actual message (translated from my language to the language of this thread):

OpenGL compositing (default) has previously caused KWin to crash. This was most likely due to a faulty driver. If you believe that in the meantime you have updated to a stable driver version, you can reset the protection function. However, be aware that this may cause an immediate crash. Alternatively, you can use the XRender backend.

(By the way, perhaps the aforementioned command I used to rashly kill kget may not have been what actually destabilised KWin?)

So does anyone recommend that I boldly activate OpenGL 3.1 (instead of OpenGL 2.0)?

The command

lspci -k

gives

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)  
        Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 4031       
        Kernel driver in use: i915                                             
        Kernel modules: i915

And there’s some additional information under KDE’s ‘Graphical Information’ for OpenGL, and then under Driver: the Renderer is listed as ‘Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)’, and the OpenGL-Version as ‘3.0 Mesa 18.0.2’.

Thank you all dear fellow SUSErs!

15

OpenGL 3 never worked for my KDE setups, and I use none of the compiz-inspired eye-candy screen effects — only Invert and Zoom (and, since I’ve been using an NVidia 1050 instead of Intel on-board graphics, I force triple-buffering). Using so little of it, I figure kwin+Plasma wouldn’t even make use of any new OpenGL 3.1 functionality anyway.

Remembering a few years ago with OpenGL 3.1, I got weird hang-ups, some pixel noise and garbled-up desktop icons when waking from standby, missing some window decorations (the window-close button regularly being just a black rectangle), and frequent notifications that kwin quit unexpectedly. However, programs such as some Steam games may be using OpenGL 3 and even Vulkan without problems on my system. For example, »vkquake« (Quake’s Vulkan port) and the Vulkan version of »The Talos Principle« run extremely well. Maybe we should give OpenGL under KDE5/Plasma/kwin another try — or ask the KDE developers whether they consider a Vulkan implementation. :wink:

16

I guess the answer to the OP’s question of whether to use OpenGL 3.1 is to try it and see.

I’m using it on a couple of nvidia setups here

paul@Orion-17:~> inxi -GG
Graphics:  Card: NVIDIA GK208B [GeForce GT 710]
           Display Server: x11 (X.Org 1.19.6 )
           drivers: nvidia (unloaded: modesetting,fbdev,nv,vesa,nouveau)
           Resolution: 1280x1024@75.02hz
           OpenGL: renderer: GeForce GT 710/PCIe/SSE2 version: 4.5.0 NVIDIA 418.56
paul@Orion-17:~>

paul@Orion-15:~$ inxi -GG
Graphics:
  Device-1: NVIDIA G84 [GeForce 8600 GTS] driver: nouveau v: kernel 
  Display: x11 server: X.Org 1.20.4 driver: nouveau 
  unloaded: fbdev,modesetting,nv,vesa resolution: 1920x1200~60Hz 
  OpenGL: renderer: NV84 v: 3.3 Mesa 19.0.1 
paul@Orion-15:~$

without any rendering problems. Provided the (driver’s) renderer supports 3.1 or greater I wouldn’t expect any problems.

17

Thank you unix111 and tannington for your helpful posts. Like unix111, I’ve also never used any fancy effects, but zooming in with Meta + = used to work before, and I’d like to be able to use this very convenient feature again.

So now I’m trying to see how I can safely reactivate the Compositor, in order to re-enable the Zoom function without causing KWin to crash.

I guess that the latest driver has been integrated to openSUSE 15.0, so there’s no need to check for updates?

Regarding the two different versions of OpenGL, namely 2.0 and 3.1: Are they equally likely to destabilise KWin (in which case I should probably avoid them both), or is one of them safer, and therefore worth a try?

I don’t know which version had been active before the crash of KWin, but, as I wrote above, the OpenGL-Version under KDE’s ‘Graphical Information’ is listed as ‘3.0 Mesa 18.0.2’.

In my case,

inxi -GG

gives

Graphics:  Card: Intel HD Graphics 530                                         
           Display Server: x11 (X.Org 1.19.6 )                                 
           drivers: modesetting (unloaded: fbdev,vesa)                         
           Resolution: 2560x1600@59.97hz                                       
           OpenGL: renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2)      
           version: 4.5 Mesa 18.0.2
18

Regarding the OpenGL 3.1 issue – I’m using it quite happily here on AMD hardware:


 > inxi -GG
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Oland PRO [Radeon R7 240/340]
           Display Server: x11 (X.Org 1.19.6 ) driver: radeon Resolution: 1920x1080@60.00hz
           OpenGL: renderer: AMD OLAND (DRM 2.50.0 / 4.12.14-lp150.12.48-default, LLVM 5.0.1)
           version: 4.5 Mesa 18.0.2
 >
19

You can temporarily toggle compositing on/off by using the Alt-Shift-F12 key combination.

       OpenGL: renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2)      
       version: 4.5 Mesa 18.0.2

The driver supports openGL 4.5, so setting the compositor to 3.1 shouldn’t present any problems… If composting works OK with 3.1 then that’s what I’d leave (KDE) set to.

I’m not too sure what the root cause of your problem actually was, have you tried creating a new user (which will use, openGL 2.0 as default if I recall correctly) to see if the problem was/is specific to your existing user profile?

20

Dear dcurtisfra and tannington, I’d like to thank you again for your kind responses, and more broadly for helping keep the collective openSUSE spirits at the unflaggingly high level befitting our genuinely friendly volunteer community!

Following tannington’s advice, I created a new user (after having installed ‘plasma5-defaults-openSUSE’) and noted that the default version of OpenGL was indeed 2.0. Then I simply logged in as myself, checked ‘Enable compositor on startup’, with the OpenGL version set to 2.0, and, voilà! No crash, and the indispensable Zoom function is working again, as desired.

So let’s admit that the shrewd, practical suggestions of this thread have triumphantly relegated this dreaded KWin crash to a soon-to-be-forgotten mishap! A plain success story, made possible by… you all know who you are.