Category: UNIX

synaptiks ist ein im KDE Umfeld angesiedeltes Programm zur Konfiguration von Touchpads (welche üblicherweise von der Fa. Synaptics stammen)

Seit synaptiks Version 0.7 steht hinter dem Programm nicht mehr der Dienst synaptiks Touchpadverwaltung – welcher automatisch in KDE gestartet wurde. Dieser sorgte dafür, dass innerhalb der KDE-Systemeinstellungen synaptiks nur konfiguriert werden musste, ohne dass man das Programm hätte explizit starten müssen.

Nun ist synaptiks ein Program ohne Dienst im Hintergrund, was folgende Auswirkungen hat:

• synaptiks funktioniert auch ohne KDE (z.B. in XFCE)
• synaptiks muss zumindest einmal explizit gestartet werden, so dass es sich im jeweiligen Tray (z.B. KDE-Kontrollleiste) verankert

In dem Snapshot sieht man die erste Seite von synaptiks, die früher in den KDE Systemsettings auftauchte. Dort sucht man sie jetzt vergebens. Dafür wird sie einem angezeigt, wenn man das Programm vom Tray aufruft.
Das wichtigste Feature ist auch gleich auf dieser Seite zu sehen: Touchpad bei Tastaturaktivität ausschalten
Der Punkt Beim Anmelden automatisch starten sollte nur aktiviert werden, wenn man den Einrichtungsdialog wirklich bei jedem login ins Windowsystem sehen möchte – ansonsten nicht anhacken. Das Tray Management von einem Windowsystem (KDE,XFCE..) kümmert sich schon um das jeweilige Einladen beim Login.

Noch eine Anmerkung: Momentan stürzt leider das Programm nach einem Wakeup von Suspend-to-RAM ab, was laut dem Autor Sebastian Wiesner bekannt und in Bearbeitung ist.

auch XFCE ist nicht von Kinder- oder Jugendkrankheiten befreit.

Falls der Auslogvorgang länger dauern sollte, im syslog eine Meldung wie folgende erscheint:
polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session21 (system bus name :1.388, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8) (disconnected from bus)

dann ist die Wahrscheinlich (zumindest bei Version 4.8.1 auf openSUSE 11.4) gross, daß beim nächsten Login die Window-Decoration fehlen und auch andere Probleme auftauchen.

Grund dafür ist sind Probleme mit dem Sessionmanager – provozieren kann man das, wenn man bspw. Firefox beendet und die Abspeicherung der vielen Daten im .mozilla Unterverzeichnis nicht abwartet, sondern sich versuch sofort abzumelden.
Dass wirft den Sessionmanager aus der Bahn, der dann bis zu seinem Timeout braucht um in diesem Fall die Session zu schliessen.

Der workaround lautet das Verzeichnis .cache des Users zu löschen.

Die heute aktuelle KDE 4.7.0 Inkarnation beglückt einem nach dem Starten der KDE Session mit 100% CPU Auslastung durch kded4

kded4 ist der KDE daemon der vorzugsweise via D-Bus Abfragen vornimmt, die Plasma Widgets dann grafisch darstellen (notifier).
Gefüttert wird der daemon durch seine Module, die sofern sie fehlerhaft sind, wie momentan

kded_networkstatus.so (in /usr/lib64/kde auf einem x64_86 System)

dann leicht in einen busy endlos-loop gerät – bei dem erwähnten Modul pollt er sich zu Tode.
Leider ist die Fehlersuche relativ mühselig – anstatt auf der Oberfläche in den KDE Systemsettings rumzuklicken, würde ich alle Verknüpfungsdateien für kded in

/usr/share/kde4/services/kded

zuerst entfernen und dann wieder Stück für Stück hineinkopieren und anschliessend in KDE einloggen um direkt die Auswirkungen des speziellen Moduls zu sehen.

Seit geraumer Zeit werde ich nach jedem Login in einem KDE4.x System zeitverzögert mit folgender Meldung beglückt:

„Nepomuk Indexing agents have been disabled“

Zusätzlich kommt noch einiges an blabla bzgl. akonadi Beschwerden.
Die Sache ist, dass ich in den KDE Systemeinstellungen nepomuk deaktiviert habe und keine KDE PIM Programme verwende. So what?

Nachdem ich mir hier nochmals die Terminologie der KDE Lieblingsprojekte verinnerlicht habe, wurde die Ursache schnell klar, auch wenn die Hintergründe es immer noch nicht sind.

Akonadi als PIM Datenzugriffsframework benötigt unbedingt nepomuk für die Umsetzung der Suche.
Warum aber starten denn überhaupt die akonadi agents? Schon der Versuch die nicht benötigten Softwarekomponenten (alles was mit akonadi und KDEpim zu tun hat) zu löschen, schlug fehl. Sie sind so stark mit dem restlichen KDE System verzahnt, dass man entweder gleich das ganze KDE System löschen oder sie eben behalten muss.
Auch ein löschen der (aus welchem Grund auch immer) schon angelegten akonadi Resourcen in den KDE Sytemeinstellungen brachte akonadi beim KDE Start nicht zum schweigen. Es scheint, dass akonadi von banalsten Programmen wie der Plasma-Uhr, benutzt wird. An dieser Stelle gab ich nach und aktivierte nepomuk (allerdings ohne den Strigi Indexer).

Dies führte dann zu dem dubiosen Fehler, dass sich nepomuk beschwerte nicht starten zu können, da das soprano backend redland fehlt. Tatsächlich waren aber alle redland Komponenten installiert. Da ich aber in den KDE Systemeinstellungen zu nepomuk nur eine Konfigurationseinstellung bzgl. des virtuoso backends gesehen habe, schwante mir wieder eine Inkosistenz – geschuldet mangelhafter Transitionsprozesse während der fortlaufenden KDE updates in der 4.x Reihe. Abhilfe schafft das Löschen folgender nepomuk Dateien:

~/.kde4/share/config/nepomuk*
~/.kde4/share/apps/nepomuk/*

Seitdem läuft nepomuk und akonadi ohne Fehlermeldungen und v.a. ressourcenschonend im Hintergrund. Lediglich nach dem Einloggen erscheinen für wenige Augenblicke die Prozesse

nepomukservicestub
akonadi_maildispatcher_agent

mit CPU Belastung.
Übrigens war dies während der inkonsistenten Phase ganz anders. Dort liefen teilweise akonadi Prozesse, sowie das benutze mysql, wild und CPU-fressend durch die Gegend.

Das nächste Echtzeit Performance Monitoring Tool. Ist aber so kompakt und einfach gehalten, dass es einfach auch hier erwähnt werden muss

AT Computing’s System & Process Monitor

Teilt den Bildschirm wie top in einen oberen Systembereich und unteren Prozessbereich auf.
Positiv fällt sofort auf, dass der Systembereich auch mit RAID/LVM und den physikalischen zugrundeliegenden Datenträgern zurechtkommt und die Last auf den einzelnen OSI Netzwerkschichten darstellen kann.

Die wichtigesten Shortcuts lauten folgendermassen:

Nachdem mit Kernel 2.6.39 der Big Kernel Lock (BLK) endgültig entfernt wurde, stellt jeder Vanilla Kernel ein vollständig konfigurierbares RT System dar.

Warum man dennoch mit Speziallösungen wie der Realtime Linux Distribution RedHawk nicht schlecht fährt liegt meist an Frontend Features welche die Wartbarkeit deutlich erhöhen.

Beispiele, gerade aus der Distribution RedHawk sind CPU-set shielding und CPU-set affinity. Beides wird mit Shell Kommandos unterstützt.

• shield kann on-the-fly CPU(s) aus der Verfügbarkeit des Operating Systems herausnehmen und wieder hinzufügen.
• run kann bestimmte Prozesse mit RT-Priorität einem bestimmten CPU-set exklusiv zuweisen (affinity).

Diese Beispiele sowie allgemeine Aktualisierungen sind in der aktuellen Fassung meines Dokumentes über Realtime Linux enthalten.