Mouse / Keyboard frieren nach KDE-Login ein – ein .cache-Problem im Plasma-Desktop

In der letzten Woche hatte ich nach einigen Updates und Experimenten mit diversen Gnome Programmen (nautilus, tracker, …) unter KDE massive Probleme mit der Maus unmittelbar nach dem Einloggen in den KDE-Desktop (Opensuse 13.2; KDE 4.14.X mit KDE 5 Komponenten). Angemerkt sei, dass ich den aktuellen proprietären Nvidia-Treiber “352.41” benutze.

Die Maus ließ sich anfangs bewegen und man konnte auch genau einmal in ein Fenster – z.B. ein Terminal – klicken. Danach zeigten weder die Maus noch Navigationstasten des Keyboards eine Wirkung – und wenn doch, dann mit ganz erheblicher Zeitverzögerung.

Das Einzige was noch funktionierte war Ctrl-Alt-Del; man konnte danach zwar unter den erscheinenden Optionen nicht mehr per Tastaur/Maus wählen – aber nach 30 sek. wurde der automatische Logout durchgeführt. Nach einem erneuten Login gab es dann seltsamerweise keinerlei Probleme mehr mit der Maus oder Tastatur.

Interessant war auch, dass das Problem offenbar User-spezifisch war. Ein initialer Login nach dem Booten unter einer anderen UserID führte zu keinen Freezes.

Es war praktisch unmöglich zu beurteilen, ob das Problem an Plasma, anderen KDE-Komponenten oder eben den Gnome-Programmen lag. Die üblichen Log-Einträge (systemd journal, .xsession-errors) gaben nichts her.

Nach ein wenig Recherche im Internet fand ich folgende Artikel:
https://bugs.kde.org/show_bug.cgi?id=341963
https://forum.kde.org/viewtopic.php?f=289&t=124690

Ich hatte keineswegs dort angesprochene Probleme mit einer voll-laufenden Partition oder ähnlichem. Aber einer der dort besprochenen Lösungsansätze half:

Nach einem Löschen der Einträge/Subverzeichnisse im Verzeichnis “~/.cache” lief alles wieder wie es sollte. Das geschilderte Problem ist seither nicht wieder aufgetaucht.

Herzlichen Dank an all diejenigen, die im Rahmen der Bewältigung ihrer eigenen Probleme das Thema potentieller “.cache”-Probleme des KDE-Plasma-Desktops herausgefunden haben! Es ist wert, diesen Punkt als KDE-Nutzer im Kopf zu behalten.

Welches der Programme, das im “.cache”-Verzeichnis Einträge hinterlegt, Schuld war, konnte ich nicht mehr nachvollziehen, da ich die “.cache”-Subverzeichnisse leider und idiotischerweise pauschal gelöscht habe. Es wäre besser gewesen, es für spätere Analysen einfach umzubenennen ….. Als potentiell schuldige Programme kommen in meinem Fall in Frage :
chromium, fontconfig, gstreamer, ibus, mozilla, tracker, webkit, xine-lib.

Kmail 4.9 – Datenverlust durch Spamfilterung

Bin letzte Woche unter Opensuse 12.1 auf KDE 4.9 umgestiegen, was mir generell ganz gut gefällt. Besonderes Augenmerk habe ich jedoch wieder mal auf KMail im Zusammenspiel mit IMAP-Servern und (OX-) Adressbüchern gelegt.

Hierzu erste Eindrücke:

Zuerst das Positive:

Mit etwas Mühe und viel Geduld kann man Kmail 4.9 im Gegensatz zu Kmail 4.8.2 – 4.8.4 x nun sogar davon überzeugen, dass die automatische Adress-Suche und -Vervollständigung beim Erstellen neuer Mails halbwegs funktioniert. (Als Linux Fan einen solchen Satz schreiben zu müssen, ist eigentlich peinlich!) Zur “address autocompletion” etwas mehr in einem späteren, separaten Beitrag.

An die Mängel bei der Adress-Autocompletion hatte man sich als Anwender ja schon seit einiger Zeit gewöhnt (siehe https://bugs.kde.org/show_bug.cgi?id=259949 ). Damit und zugehörigen Workarounds kann man leben

Nun aber das Negative:

Der Suchdialog funktioniert nach wie vor nicht:
Der Kmail-Suchdialog zum Suchen von Mails ist nach wie vor nicht benutzbar. Bei mir werden nun gar keine Treffer mehr angezeigt. Das ist fast besser als das, was früher am Schirm erschien. Also: Das Einzige, was bzgl. der Suche von Mails wirklich funktioniert, ist unter Kmail die Schnellsuchleiste oberhalb der Anzeige der Mailliste. Alles andere funktioniert nicht oder nicht richtig. Dieser Punkt allein disqualifiziert Kmail im Moment für den professionellen Einsatz.

Leider, leider, leider … Viel schlimmer ist aber noch Folgendes: Im Moment besteht die Gefahr eines (ggf. umfänglichen) Datenverlustes durch Spamfilterung an KDE’s E-Mail-Client.

Spamfilter eliminieren Mailinhalte:
Meine Frau hat gestern Abend Bogofilter für die Spam-Elimination auf ihrem Kmail eingerichtet. Hauptgrund ist, dass sie auch Mailkonten auf externen IMAP-Servern und nicht nur unserem eigenen benutzt. (Auf unserem eigenen Server werkelt Spamassassin und macht dort einen guten Job). Der Einsatz von Bogofilter unter Kmail sah anfänglich auch gut aus. Mails, die bereits als gelesen markiert waren und danach der Spamfilterung unterzogen wurden, wurden richtig und wie in den Filtereinstellungen vorgesehen behandelt. Die große Überraschung kam jedoch am nächsten Morgen:

Aus allen neuen Mails, die von Bogofilter als Spam eingestuft wurden, wurde der Mail-Body entfernt. Sprich: Diese Mails waren danach leer!

Dies betraf alle neuen ungelesen Mails – egal aus welcher IMAP-Quelle. Das ist keineswegs nur ein Darstellungsproblem am (K-)Mail-Client: Die Mails werden über Akonadi als leere Mails mit den jeweiligen IMAP-Server “abgeglichen”. Ein kurzer Test zeigte übrigens, dass das gleiche Problem unter Kmail auch bei Einsatz des Perl-basierten Spamassassin auftritt.

Irgendwie führt die Modifikation des Mailheaders durch Bogofilter/Spamassassin am Kmail-Client dazu, dass im Zusammenspiel von KMail – Akonadi – IMAP-Server die Mailinhalte von Mails gelöscht werden, die noch nicht als gelesen markiert wurden.

Nebenbei: Ein weiterer Bug ist der, dass diese derart malträtierten Mails nicht – wie in den Filterregeln vorgesehen – in einen SPAM-Ordner verschoben wurden. Und Spamassassin braucht beim Durchkämmen von größeren Verzeichnissen unglaublich viel CPU. Aber was solls … ich rege mich nicht mehr auf – sonst kommt gleich wieder ein Entwickler und macht mich mit Nachdruck darauf aufmerksam, dass seine Arbeit freiwillig ist und nicht bezahlt wird. (Das finde ich auch schlimm, meine aber trotzdem, dass SW-Qualität primär etwas mit vernünftigen Change Management und Release-Prozessen zu tun hat …)

Jedenfalls finde ich: Das Entfernen des Mailinhalts macht nicht nur keinen Spaß – das ist ein echtes Problem ! Und es ist keineswegs neu – wie ich nach ein wenig Recherche lesen musste:
https://bugs.kde.org/show_bug.cgi?id=295484

Ich habe die Spamfilterung bei meiner Frau jedenfalls vorläufig abgestellt. Sie hofft jetzt auf bessere Zeiten und sucht mal wieder nach Alternativen …

Um böse Überraschungen zu vermeiden, kann ich jedem Kmail-Anwender im Moment nur raten, Spam-Filter vor einem Einsatz wirklich ausführlich zu testen und auf umfängliche Trainingsläufe mit produktiven Mailfoldern zu verzichten – bis man sicher ist, dass nichts passiert.

Fazit:
Seit der Einführung von Akonadi, Nepomuk, Strigi reißen die Probleme mit Kmail für die Anwender leider immer noch nicht ab.

Kmail 4.8 – Suchfunktionalität weiterhin im Eimer

Seit der Umstellung auf das akonadi-basierte Kmail2 (unter Opensuse passierte das nach KDE 4.6.4) gibt es Probleme mit der Suche nach Mails unter Kmail. Diese Feststellung ist mehr als traurig, denn im täglichen professionellen Einsatz von Mail-Programmen benötigt man Suchfunktionen, die einen schnell mehrere Suchkriterien miteinander kombinieren lassen – z.B. für den Mail-Text und für das Absender-Feld.

Kmail 1.13.7 wies hierfür einen voll funktionsfähigen eigenen Such-Dialog auf. Auf einem unserer Rechner ist die alte Version noch unter KDE 4.6.4 installiert. Da läuft alles noch prima – auch im Zusammenspiel mit IMAP-Servern.

Wie ist der Zustand seit KDE 4.7 und auch jetzt noch unter KDE 4.8 ?

  • Weder unter Kmail 4.7.4 noch unter Kmail 4.8 gibt der Suchdialog einem eine Möglichkeit zur Eingabe eines Mailverzeichnisses, den man durchsuchen will.
  • Wenn gesucht wird, so wird (manchmal) in allen Mailverzeichnissen gesucht.
  • Unter KDE 4.7.4 liefern viele Suchvorgänge Ergebnislisten mit leeren Zeilen am Anfang.
  • Unter KDE 4.8 liefert eine Suche mit mehreren kombinierten Such-Kriterien leere Resultsets, obwohl es viele Mails gibt, die die Kriterien erfüllen.
  • Manche Suchen nach Begriffen im vollständigen Mailtext liefern Resultsets – aber auch die nicht immer zuverlässig. Die Suchergebnisse sind nicht immer vollständig.

Das Ganze ist so fehlerhaft, dass man den Suchdialog unter Kmail im Moment als nicht benutzbar ansehen muss. Im Grunde ein Desaster! Hingewiesen hat mich darauf übrigens Martin Lüchem. Ich wollte es ihm zunächst gar nicht glauben, aber leider hat er recht.

Die einzige Suche, die bei mir z.Z. noch funktioniert, ist die über die Eingabezeile im normalen Kmail-Fenster. Das ist eine Volltext-Suche. Die scheint zu klappen. Aber wie gesagt, das reicht für den professionellen Einsatz überhaupt nicht.

Da fragt sich der KDE-Anwender erneut: Wie kann es sein, dass sich solche Mängel über zwei größere Releases von KDE 4 hinweg halten können?