plasma-desktop friert ein beim Abziehen des Strom-Kabels

Deutsch (German) KDE
#1

Hallo liebes Forum,

auf meinem Laptop mit OpenSuse 13.2 und KDE 4.14.2 habe ich schon seit einiger Zeit das Problem, dass plasma-desktop sofort einfriert, wenn ich Stromkabel vom Laptop trenne.
I.d.R. kommt so was auch beim Anschluss von externen Geräten (z.B. USB-Stick oder externe Festplatte) ans Laptop vor.
In solchen Fällen versuche ich über die Konsole Prozess-ID von plasma-desktop rauszufinden, den Prozess zu killen und dann plasma-desktop neu zu starten. In manchen Fällen funktioniert das, in manchen Fällen hilft nur ein Neustart des Rechners.
Ich habe bereits versucht, die Einstellungen von plasma-desktop zurückzusetzen, indem ich entsprechende Dateinen (die mit plasma beginnen) in den Ordnern ~/.kde4/share/apps und ~/.kde4/share/config gelöscht habe. Das hat aber leider nichts gebracht.
Ich habe vor kurzem ein Upgrade von OpenSuse 13.1 auf OpenSuse 13.2 gemacht - das Problem hat aber damit nichts zu tun, da es noch vor dem Upgrade bestanden hat.

Ich würde mich über jede Hilfe freuen. Falls noch irgendwelche Angaben benötogt werden, bitte Bescheid geben.

Viele Grüße,
ytseserg

#2

Hm.
Hilft es, den Dienst “Energieverwaltung” abzuschalten?
(in KDE’s Systemeinstellungen->Starten und Beenden->Diensteverwaltung)

#3

Ich habe es gerade ausprobiert und es hat leider das Problem nicht behoben.

#4

Hm.
Du sagst, das passiert auch wenn du externe Festplatten/USB sticks ansteckst?
In all diesen Fällen wird von Plasma eine Notification angezeigt.

Wenn er immer beim Anzeigen einer Notification hängenbleibt, könnte das auf ein Grafiktreiberproblem hinweisen.
Probier doch bitte mal in den “Wiederherstellungsmodus” zu booten (oder “Recovery Mode”, erreichbar im Bootmenü unter “Erweiterte Optionen”/“Advanced Options”). Hast du das gleiche Problem dort auch?

#5

Danke für die schnelle Antwort.
Ich habe im Bootmenü kein “Recovery”-Modus, sondern nur “failsafe”-Modus. Hier der entsprechende Auszug aus der Datei /boot/grub/menu.lst:

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE - 3.16.6-2
    root (hd0,4)
    kernel /boot/vmlinuz-3.16.6-2-desktop root=/dev/disk/by-id/ata-PLEXTOR_PX-256M5Pro_P02302101506-part5 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe
    initrd /boot/initrd-3.16.6-2-desktop

Ich habe ein bißchen recherchiert und soweit ich das verstanden habe, ist “Recovery”-Modus und “failsafe”-Modus mehr oder weniger dasselbe. Oder irre ich mich da? Wenn ja, dann bitte korrigieren.
Jedenfalls habe ich versucht, OpenSuse im failsafe-Modus zu booten und habe festgestellt, das dieses Problem dort auch auftritt. Was könnte ich noch tun?

#6

Ist das selbe, ja.
Du benutzt also noch GRUB1, dort wird ein “failsafe” Eintrag angelegt, bei GRUB2 heißt der eben “Recovery Mode”.

Jedenfalls habe ich versucht, OpenSuse im failsafe-Modus zu booten und habe festgestellt, das dieses Problem dort auch auftritt. Was könnte ich noch tun?

Hm.
Kannst du vielleicht mal in z.B. IceWM einloggen und das Strom-Kabel abziehen?
Dann könnte man zumindestens sagen, ob KDE mit dem Problem im Zusammenhang stehen könnte oder nicht.
IceWM sollte standardmäßig installiert sein, um es auszuwählen musst du am Login-Bildschirm auf das “Schraubenschlüssel” Symbol links unten klicken.

Du kannst natürlich auch jeden anderen Desktop nehmen, falls installiert. Die Liste zeigt aber eh nur die an die verfügbar sind… :wink:

Wenn du Auto-Login aktiv hast, melde dich einfach ab (nicht Herunterfahren!) und du solltest zum Anmeldebildschirm kommen.

Was vielleicht auch noch interessant sein könnte:
Starte “dmesg -w” in einem Terminalfenster (konsole z.B.). Dann reproduziere das Problem.
Kommen irgendwelche Meldungen in dem Fenster?
Und das gleiche mit:

tail -f ~/.xsession-errors-:0
#7

Hallo,

ich war einige Zeit weg und habe mich deswegen nicht sofort zurückgemeldet. Danke für die ausführliche Antwort.
Das ist ein reines KDE-Problem. Wenn ich beim Anmelden z.B. Xfce oder LFDE als Desktop-Umgebung auswähle, dann tritt dieses Problem dort nicht auf.

Ich habe gerade festgestellt, dass beim Boot nfs-Service nicht richtig gestartet ist. Da ich nfs-Freigabe auf meinem NAS-Server nicht besonders häufig nutze, ist mir das nicht sofort aufgefallen.
Offenbar liegt es daran, dass beim Starten des nfs-Dienstes Netwerkverbindung noch nicht vorhanden ist - aus diesem Grund kann nfs-Dienst beim Boot nicht richtig gestartet werden. Wenn ich nfs-Dienst manuell mit folgendem Befehl starte:

systemctl restart nfs

, dann tritt das Problem mit plasma-desktop danach nicht mehr auf. Damit nfs-Dienst bei Boot richtig startet, habe ich ein bißchen recherchiert und den Parameter NM_ONLINE_TIMEOUT von 0 auf 30 geändert (in /etc/sysconfig in Yast unter Network > General). Soweit ich das verstanden habe, hat diese Änderung zur Folge, dass beim Start des nfs-Dienstes beim Hochfahren darauf gewartet wird, dass die Netwerk-Verbindung da ist.

Ich weiß wirklich nicht, in welchem Zusammenhang nfs-Dienst mit den Abstürzen von plasma-desktop steht, aber seitdem ich die o.g. Änderungen gemacht habe, stürzt plasma-desktop nicht mehr ab. Möglicherweise versucht plasma-desktop beim nicht richtig gestartetem nfs-Dienst eine Meldung anzuzeigen, die letztendlich den Absturz verursacht. Ich weiß es nicht…
Ich werde das noch einige Zeit beobachten und posten, wenn sich etwas ändert, aber es sieht soweit ganz gut aus.

#8

Ok, dann war das mit dem Stromkabel also nur Zufall…
Das hängen beim Verbinden von Wechselmedien hängt aber damit zusammen.

Offenbar liegt es daran, dass beim Starten des nfs-Dienstes Netwerkverbindung noch nicht vorhanden ist - aus diesem Grund kann nfs-Dienst beim Boot nicht richtig gestartet werden. Wenn ich nfs-Dienst manuell mit folgendem Befehl starte:

systemctl restart nfs

, dann tritt das Problem mit plasma-desktop danach nicht mehr auf. Damit nfs-Dienst bei Boot richtig startet, habe ich ein bißchen recherchiert und den Parameter NM_ONLINE_TIMEOUT von 0 auf 30 geändert (in /etc/sysconfig in Yast unter Network > General). Soweit ich das verstanden habe, hat diese Änderung zur Folge, dass beim Start des nfs-Dienstes beim Hochfahren darauf gewartet wird, dass die Netwerk-Verbindung da ist.

Ja. Das 30 ist übrigens nur das maximale Timeout, du kannst da auch jeden beliebigen anderen Wert nehmen (0 bedeutet “kein Warten”).

Wenn du aber sowieso nur eine Kabelnetzwerkverbindung hast, kannst du NetworkManager aber auch genausogut abschalten, und “Traditionelle Methode via ifup” bzw. “Wicked Dienst” (bei 13.2) ausprobieren. (YaST->Netzwerkgeräte->Netzwerkeinstellungen->Globale Optionen)

Soweit ich weiß gibts auch einen “soft” Parameter für NFS, der zumindest das “Einfrieren” verhindern sollte:
Aus “man nfs”:

      **soft** / **hard**    Determines the recovery behavior of the NFS client after
                      an  NFS  request times out.  If neither option is speci-
                      fied (or if the **hard** option is specified), NFS  requests
                      are  retried indefinitely.  If the **soft** option is speci-
                      fied, then the NFS client fails  an  NFS  request  after
                      **retrans**  retransmissions have been sent, causing the NFS
                      client to return an error to the calling application.

Hab aber nfs selber noch nie benutzt…

Ich weiß wirklich nicht, in welchem Zusammenhang nfs-Dienst mit den Abstürzen von plasma-desktop steht, aber seitdem ich die o.g. Änderungen gemacht habe, stürzt plasma-desktop nicht mehr ab. Möglicherweise versucht plasma-desktop beim nicht richtig gestartetem nfs-Dienst eine Meldung anzuzeigen, die letztendlich den Absturz verursacht. Ich weiß es nicht…

Das ist ein bekanntes Problem, dass Plasma einfriert wenn NFS-Shares nicht erreichbar sind. (eigentlich ist es ja NFS das hängt)
Z.B. das K-Menü zeigt ja eine Liste aller “Wechselmedien” an, das greift auch auf die NFS-Shares zu, wenn es schaut welche Datenträger vorhanden sind. Und der Device-Manager wohl auch.

#9 
Wenn du aber sowieso nur eine Kabelnetzwerkverbindung hast, kannst du NetworkManager aber auch genausogut abschalten, und "Traditionelle Methode via ifup" bzw. "Wicked Dienst" (bei 13.2) ausprobieren. (YaST->Netzwerkgeräte->Netzwerkeinstellungen->Globale Optionen)

Ich nutze i.d.R. nur WLAN, daher bleibe ich lieber beim NetworkManager

Soweit ich weiß gibts auch einen "soft" Parameter für NFS, der zumindest das "Einfrieren" verhindern sollte:
Aus "man nfs":


  **soft** / **hard**    Determines the recovery behavior of the NFS client after
                  an  NFS  request times out.  If neither option is speci-
                  fied (or if the **hard** option is specified), NFS  requests
                  are  retried indefinitely.  If the **soft** option is speci-
                  fied, then the NFS client fails  an  NFS  request  after
                  **retrans**  retransmissions have been sent, causing the NFS
                  client to return an error to the calling application.


Hab aber nfs selber noch nie benutzt...

Der Parameter war bei mir in /etc/fstab nicht gesetzt (soweit ich die Dokumentation verstanden habe, ist hard die Default-Einstellung). Ich habe es nun auf soft eingestellt.

Da das Problem nun nicht mehr auftritt, könnte man m.E. diesen Thread auf gelöst setzen bzw. schließen.