I have a sneaking suspicion that I’m the only guy on earth that is interested in this setup, but who knows?
I’m running KDE 4.65 Max OSX 10.5.8 via MacPorts.
bash-3.2$ port info kdebase4 kdebase4 @4.6.5, Revision 1 (kde, kde4) Replaced by: kde4-baseapps Variants: debug, docs, universal Description: Core desktop applications and libraries for the KDE4 desktop. This port installs the file manager dolphin file manager. Homepage: http://www.kde.org Build Dependencies: cmake, pkgconfig, automoc Library Dependencies: qt4-mac, phonon Platforms: darwin License: unknown Maintainers: email@example.com, firstname.lastname@example.org
It could seem like an odd choice running KDE on OS X, I know, the reason I do it is to gain access to the KDE Semantic project Nepomuk.
I’m planning more posts that will elaborate on why, and what is it that I’m doing with nepomuk but this post is much more specific and narrow in scope.
Having started to use nepomuk to tag my various files I have been constantly bothered by a process seriously hammering my cpu (and the hard drive).
The process name was nepomukservicestub, but I had a few instances of this process distinguished by a string parameter I could see with ps
bash-3.2$ ps -ef | grep -i nepomukservicestub .../MacOS/nepomukservicestub nepomukstorage .../MacOS/nepomukservicestub nepomukqueryservice .../MacOS/nepomukservicestub nepomukremovablestorageservice .../MacOS/nepomukservicestub nepomukbackupsync .../MacOS/nepomukservicestub nepomukstrigiservice
the one instance eating up my cpu was “nepomukstrigiservice”. now strigi is a well known(tm) file indexing service being used by nepomuk to populate parts of it’s own database. for reason I’ll go into in a future post I have no immediate use for the data generated by strigi.
so I decided to disable strigi rather than trying to fix the obvious problem with it (I had enough distraction as it is now, anyway).
strigi does come with a a control app called “strigiclient” however clicking the stop button on it had no effect on the nepomukstrigiservice that kept consuming above 90% of my poor MacBook Pro CPU cycles.
what I end up doing is using the dbus interface to nepomuk itself, ended up using dbus-tools from here checking out their SVN repo.
I wanted to share the command that had the load taken off my poor cpu, let me stress: this is useful under specific terms since it leaves nepomuk functional but on the other hand it disables the automatic indexing. for a lot of users (I’m tempted to say most) this will leave the system in a rather pointless state as the text (and possibly other properties) of new files will not be indexed!.
with that warning in mind here is the command I used to get rid of this process:
dbus org.kde.NepomukServer /servicemanager stopService %'"nepomukstrigiservice"'
where dbus is the dbus-tools executable.