Tonight my netbook kept running and in the morning I noticed that the ~/.xsession-errors grow up close to 270 MB. Most (~240 MB) of that comes from

Code: Select all

[/usr/bin/nepomukservicestub] "/usr/bin/nepomukservicestub(1374)" Error in thread 3052444528 : "org.freedesktop.DBus.Error.UnknownObject - No such object path '/org/soprano/Server/models/main'"


Anyone an idea what is wrong?

This is a bug in the Nepomuk Service that is producing that error message. If you are using KDE 4.4.4, please file a bug report at bugs.kde.org.

Thanks for the hint. Actually I am not so sure if it is a bug, but found a bug report Bug #226356 in which is suggested that "something crashed". When trying to restart Strigi and Nepomuk, Virtuoso did not want to start. Also restarting the whole maschine initially did not help. Since the last distribution and also KDE upgrade is not so long in the past, I moved ~/.kde/share/config/nepomukserverrc to my backup folder and restarted again.

Now virtuoso-t and nepomukservices are happily chewing on my cpu-time again and .xsession-errors is not flooded with nepomuk-errors any more. Nice.

Since I enabled/disbled Nepomuk and Strigi several times during KDE-sessions, I am not sure how relevant the diff between the old and new nepomukserverrc is, but I post it the files here anyway. Maybe someone will find it helpful:

old:

Code: Select all

[Basic Settings]
Configured repositories=main
Start Nepomuk=false

[Service-nepomukmigration1]
autostart=false

[Service-nepomukstrigiservice]
autostart=false

[main Settings]
Maximum memory=50
Storage Dir[$e]=$HOME/.kde/share/apps/nepomuk/repository/main/
Used Soprano Backend=virtuosobackend
index version=2


new:

Code: Select all

[Basic Settings]
Start Nepomuk=true

[Service-nepomukstrigiservice]
autostart=true

[main Settings]
Maximum memory=50
Storage Dir[$e]=$HOME/.kde/share/apps/nepomuk/repository/main/
Used Soprano Backend=virtuosobackend


Ok things seem to be more complicated, .xsession-error filled up with the same message again. Wondering whal is happening there, I tried to recall adaptions I made to the standard configurations. I had troubles with Akonadi not really working if started together with Kontact. I had to end Kontact and start it again. Therefore I put "akonadictl start" into kde autostart and Akonadi worked directly. Good.

Well not really. Unfortunately then I can not find the virtuoso process anymore, nepomuk floods .xsession-errors and the desktop search fails. If I exclude "akonadictl start" from autostart the desktopsearch works again.

Damn. So it seems I have to exclude Kontact from session management and start Akonadi manually before starting Kontact.

What I do not get at the moment why it worked when I removed the nepomuk config file.

i have same problem and i see that nepomuk bug depends on akonadi: infact if i don't start akonadi, nepomuk works fine. With kde 4.4.3 there wasn't this bug.

Interesting. Can you please ensure that all Akonadi packages are up to date?

bcooksley wrote:Interesting. Can you please ensure that all Akonadi packages are up to date?

yes, all daily updated. I have installed these packages:
ii akonadi-kde-resource-googledata 1.0.1-1build1 Google calendar and contacts resource for Ak
ii akonadi-server 1.3.1-0ubuntu3 Akonadi PIM storage service
ii kdepim-runtime 4:4.4.4-0ubuntu1~lucid1~ppa1 Runtime components for akonadi-kde
ii libakonadiprivate1 1.3.1-0ubuntu3 libraries for the Akonadi PIM storage servic
ii libakonadiprivate1 1.3.1-0ubuntu3 libraries for the Akonadi PIM storage servic

Please file a bug at bugs.kde.org, as there appears to be some issue with the interaction between Nepomuk and Akonadi ( potentially meaning that Akonadi's search capabilities will not function fully )

bcooksley wrote:Please file a bug at bugs.kde.org, as there appears to be some issue with the interaction between Nepomuk and Akonadi ( potentially meaning that Akonadi's search capabilities will not function fully )

i already report bug on bugs.kde.org