Nepomuk und Akonadi im Griff

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.