0

This is a tale of two 64-bit Mageia 5 GNU/Linux systems equipped with 6xx/7xx nVidia video cards. Each is configured with a KDE4 desktop (task-kde4-minimal-4.14.3-2.mga5), and use a proprietary driver supplied by the distribution (nvidia-current-kernel-desktop-latest-352.79-10.mga5.nonfree). The proprietary driver is required because nouveau is inadequate for some applications. One system seems to work just fine, but another has a most annoying quirk that I don't see happening on the other system:

If a particular application is closed, when it shuts down, the desktop
immediately goes to a black screen such that the monitor says the
signal is out of range.

A reboot does not fix the problem. The graphical login (kdm-4.11.16-5.mga5) works just fine, but as soon as one logs into a user account with a KDE desktop, the problem recurs.

The solutions posted for What to do when a linux desktop freezes? were considered by do not appear to be effective.

Reconfiguring xorg has no impact other than to change how kdm configured the display. KDE overrides whatever configuration is set up at the xorg level.

After the fault, I have not found any keys including Ctrl-Alt-Backspace that can recover some control of the graphical desktop, but I can switch to a console with Ctrl-Alt-F2, and I can attempt recovery.

Edit: Actually, Ctrt-Alt-Backspace does work, it just takes either patience or multiple attempts.

After the fault, I can get into a failsafe graphical desktop that is a really minimal environment. It works fine.

After much gnashing of teeth, I found that stopping the desktop manager and deleting the ~/kde4 folder recovers system behavior:

# service dm stop
# rm -rf /home/user/.kde4
# service dm start

This is a horrible workaround, not to mention that it requires elevated privileges to run.

By the way, the "particular application" is MineCraft 1.8.9 running under java (jre1.8.0_91), but this question is not about why it does that or how to prevent it. Rather, it is about how one debugs KDE4 breakage of this nature however it may have happened.

Is there a KDE-specific command-line utility that might be off assistance in a scenario like this?

Community
  • 1
kbulgrien
  • 830

1 Answers1

0

No elevated permissions are required, and reboot is unnecessary.

  • Kill KDE with Ctrl-Alt-Backspace.
  • Use Ctrl-Alt-F2 (or another Function key as needed) to get a console.
  • Log on as the user that triggered the problem.
  • For safety, backup ~/.kde4/share/apps/kscreen/????????????????????????????????
  • Delete ~/.kde4/share/apps/kscreen/????????????????????????????????

In this specific instance, given the details in the question, the actual file name ws cc3277aaebc0a310157f935da894a119, but the file name changes when the .kde4 folder structure is rebuilt.

How did I arrive at this conclusion? First, I triggered the desktop failure, killed the KDE with Ctrl-Alt-Backspace, renamed the broken copy of ~/.kde, restarted KDE, then diff'd the good directory with a broken one:

$ diff -qr .kde4 kde4.broke
Files .kde4/share/apps/activitymanager/activityranking/database and kde4.broke/share/apps/activitymanager/activityranking/database differ
Files .kde4/share/apps/kconf_update/log/update.log and kde4.broke/share/apps/kconf_update/log/update.log differ
Files .kde4/share/apps/kscreen/cc3277aaebc0a310157f935da894a119 and kde4.broke/share/apps/kscreen/cc3277aaebc0a310157f935da894a119 differ
Files .kde4/share/apps/kwallet/kdewallet.kwl and kde4.broke/share/apps/kwallet/kdewallet.kwl differ
Files .kde4/share/apps/kwallet/kdewallet.salt and kde4.broke/share/apps/kwallet/kdewallet.salt differ
Files .kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.db and kde4.broke/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.db differ
Files .kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso-temp.db and kde4.broke/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso-temp.db differ
Files .kde4/share/config/activitymanagerrc and kde4.broke/share/config/activitymanagerrc differ
Files .kde4/share/config/gtkrc and kde4.broke/share/config/gtkrc differ
Files .kde4/share/config/gtkrc-2.0 and kde4.broke/share/config/gtkrc-2.0 differ
Files .kde4/share/config/kdebugrc and kde4.broke/share/config/kdebugrc differ
Files .kde4/share/config/kdeglobals and kde4.broke/share/config/kdeglobals differ
Files .kde4/share/config/kglobalshortcutsrc and kde4.broke/share/config/kglobalshortcutsrc differ
Files .kde4/share/config/khotkeysrc and kde4.broke/share/config/khotkeysrc differ
Files .kde4/share/config/klipperrc and kde4.broke/share/config/klipperrc differ
Files .kde4/share/config/plasma-desktop-appletsrc and kde4.broke/share/config/plasma-desktop-appletsrc differ

Differences in only one file seemed certain to be related:

$ diff -u .kde4/share/apps/kscreen/cc3277aaebc0a310157f935da894a119 kde4.broke/share/apps/kscreen/cc3277aaebc0a310157f935da894a119
--- .kde4/share/apps/kscreen/cc3277aaebc0a310157f935da894a119   2016-07-04 02:47:56.312121742 -0500
+++ kde4.broke/share/apps/kscreen/cc3277aaebc0a310157f935da894a119      2016-07-02 23:51:04.725895881 -0500
@@ -1 +1 @@
-[ { "enabled" : true, "id" : "39a867a4a7600077629a3c27c6fa77bf", "metadata" : { "fullname" : "xrandr-hp L2335-CNP509Z1GW", "name" : "DVI-I-1" }, "mode" : { "refresh" : 59.9502, "size" : { "height" : 1200, "width" : 1920 } }, "pos" : { "x" : 0, "y" : 0 }, "primary" : true, "rotation" : 1 } ]
\ No newline at end of file
+[ { "enabled" : true, "id" : "39a867a4a7600077629a3c27c6fa77bf", "metadata" : { "fullname" : "xrandr-hp L2335-CNP509Z1GW", "name" : "DVI-I-1" }, "mode" : { "refresh" : 59.8846, "size" : { "height" : 1200, "width" : 1920 } }, "pos" : { "x" : 0, "y" : 0 }, "primary" : true, "rotation" : 1 } ]
\ No newline at end of file

Notice the difference seems small and innocuous: 59.9502 vs. 59.8846

Most of other file differences result from a creation date and show no functional difference, or are related to application environment rather than the desktop manager. One mentioned the "Desktop", but the difference was only in GUID - hardly likely to be directly related to the problem.

To test my hypothesis, I saved a good copy of .kde4/share/apps/kscreen/cc3277aaebc0a310157f935da894a119, triggered the desktop failure, and instead of deleting the file, I copied the known good file over the one that was changed after the system failed. KDE recovered.

Next, since most people won't have a good copy of the file on hand, I decided to try deleting it instead of "fixing" it. Deleting the file also recovered the desktop.

kbulgrien
  • 830