I had the same problem and "killall kactivitymanagerd" solved it for me. However, it didn't happen since then which was 2 days ago. It seems like a rare event.

The cause for this is a broken Nepomuk setup.

Make sure you have the compatible versions of all needed packages to run Nepomuk properly.

I'm leaving this open so that I remember to make it work even on broken setups :)

(In reply to comment #2)
> The cause for this is a broken Nepomuk setup.
> 
> Make sure you have the compatible versions of all needed packages to run
> Nepomuk properly.
What does that mean?
I am running a complete kde-4.8.2-setup, soprano-2.7.5, dbus-1.4.20, qt-4.8.1, virtuoso-6.1.4 (anything more, that could be interesting?), and I also get these freezes (plasma-desktop). I use IconTasks (the one shipped with kde since 4.8.0 (?)), and clicking left/middle mouse on an icon freezes the desktop.

I confirm the problem with KDE 4.9 rc2 with Gentoo too.

I cannot find anywhere the list of the required packages/versions for Nepomuk. 
If a dev knows what can be the problem, could he explain it to allow us to correct this bug ?

[IP-] [  ] dev-db/virtuoso-odbc-6.1.5:0
[IP-] [  ] dev-db/virtuoso-server-6.1.5:0
[IP-] [  ] app-misc/strigi-0.7.7-r1:0
[I-O] [  ] dev-libs/soprano-2.8.0:0
[I-O] [  ] kde-base/kdegraphics-strigi-analyzer-4.8.97:4
[I-O] [  ] kde-base/kdepim-strigi-analyzer-4.8.97:4
[I-O] [  ] kde-base/kdesdk-strigi-analyzer-4.8.97:4
[I-O] [  ] kde-base/nepomuk-4.8.97:4
[I-O] [  ] kde-base/nepomuk-core-4.8.97:4

I can reproduce this in 4.9RC2 as well.

When I go to the system settings, disable and then re-enable Nepomuk, it causes kactivitymanagerd to go all the way up to about 100% CPU which then causes Dolphin to freeze when I right click inside the file view bringing this kind dbus timeout messages to .xsession-errors:

dolphin(9568) KActivities::Consumer::listActivities: d-bus reply was invalid () QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.")
dolphin(9568) KBookmarkManager::notifyChanged: KBookmarkManager::notifyChanged (  "" )

After a minute or so also Plasma freezes.

When debugging for kactivitymanagerd is on, my .xsession-errors also fills with messages like:

"/usr/bin/kactivitymanagerd(8912)" Soprano: "Failed to write to fd 11 (Broken pipe)"
"/usr/bin/kactivitymanagerd(8912)" Soprano: "Failed to write unsigned int32."

Killing frozen Plasma works, but I can't restart it until I have killed and restarted kactivitymanagerd (restarting that alone without killing plasma first also works around the problem).

I cannot reproduce the behavior in my Project Neon VM, though.

Still reproducible in 4.9.0 as described in my comment above.

"/usr/bin/kactivitymanagerd(8912)" Soprano: "Failed to write to fd 11 (Broken pipe)" "/usr/bin/kactivitymanagerd(8912)" Soprano: "Failed to write unsigned int32."

This implies broken nepomuk/soprano setup. You should contact nepomuk guys (IRC #kde-nepomuk) to debug.

It's actually #nepomuk-kde, but I'll do that.

I know about this problem - Trying to fix it.

I decided to tackle this bug today, and despite my best efforts I could not reproduce it.

If someone can reproduce is, could they please provide me with the full backtrace? The backtrace that has been attached only has information about one thread.

This should do the trick -

> attach <pid>
> thread apply all backtrace
> detach <pid>

Thanks

Backtrace of what?
BTW you won't probably notice anything after restarting Nepomuk until you open a Dolphin window and right click somewhere in the file view.

I can reproduce this here reliably 100% of the time.

(In reply to comment #11)
> Backtrace of what?
In your case dolphin.

> BTW you won't probably notice anything after restarting Nepomuk until you
> open a Dolphin window and right click somewhere in the file view.
> 
> I can reproduce this here reliably 100% of the time.

This is what I've been doing -
1. Start Nepomuk
2. Start dolphin/krunner/kactivitymangaerd
3. Switch of Nepomuk
4. Use th specified application, and wait for it to go mad.

How are you going about it?

Stupid question: how do I get a backtrace of a program that is not crashing?
I started it with gdb, but I only get some debug messages (when turning them one using kdebugdialog).

When I start Dolphin I get:

Starting program: /usr/bin/dolphin 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffd78e3700 (LWP 13534)]
QPixmap::scaled: Pixmap is a null pixmap
QPixmap::scaled: Pixmap is a null pixmap
QPixmap::scaled: Pixmap is a null pixmap
[New Thread 0x7fffd6a63700 (LWP 13540)]
dolphin(13518) KSambaSharePrivate::testparmParamValue: Running testparm ("-d0", "-s", "--parameter-name", "usershare path")
[New Thread 0x7fffd5081700 (LWP 13547)]
[Thread 0x7fffd5081700 (LWP 13547) exited]
[New Thread 0x7fffd5081700 (LWP 13548)]
[Thread 0x7fffd5081700 (LWP 13548) exited]
[New Thread 0x7fffd5081700 (LWP 13549)]
[Thread 0x7fffd5081700 (LWP 13549) exited]
dolphin(13518) KDirListerCache::listDir: Listing 59 cached items soon
dolphin(13518)/kdecore (services) KServicePrivate::init: The desktop entry file  "/home/janek/.directory"  has Type= "Application"  but no Exec line

And some time later:

dolphin(13518) KActivities::Consumer::isResourceLinkedToActivity: d-bus reply was invalid false QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.")
dolphin(13518) KActivities::Consumer::listActivities: d-bus reply was invalid () QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.")
dolphin(13518) KBookmarkManager::notifyChanged: KBookmarkManager::notifyChanged (  "" )

while my .xsession-errors fills with the "broken pipe" messages I posted above.

You get the pid of the process by `pidof dolphin`. Or you can use ps aux | grep dolphin.

Once you have that you run 
$gdb
attach <pid>
thread apply all backtrace
detach <pid>

That should give you the backtrace.

This is what I get:

0x00007f91b8267573 in poll () from /lib64/libc.so.6

Thread 3 (Thread 0x7f919a545700 (LWP 14058)):
#0  0x00007f91b8267573 in poll () from /lib64/libc.so.6
#1  0x00007f91b51df796 in g_main_context_iterate.isra.23 () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f91b51df8c4 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f91b98bb1ff in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/qt4/libQtCore.so.4
#4  0x00007f91b988adf2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/qt4/libQtCore.so.4
#5  0x00007f91b988b047 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/qt4/libQtCore.so.4
#6  0x00007f91b978afd7 in QThread::exec() () from /usr/lib64/qt4/libQtCore.so.4
#7  0x00007f91b986ac0f in QInotifyFileSystemWatcherEngine::run() () from /usr/lib64/qt4/libQtCore.so.4
#8  0x00007f91b978dffb in QThreadPrivate::start(void*) () from /usr/lib64/qt4/libQtCore.so.4
#9  0x00007f91b94f7e2c in start_thread () from /lib64/libpthread.so.0
#10 0x00007f91b82701dd in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f91996c5700 (LWP 14064)):
#0  0x00007f91b8269bb3 in select () from /lib64/libc.so.6
#1  0x00007f91b986a281 in QProcessManager::run() () from /usr/lib64/qt4/libQtCore.so.4
#2  0x00007f91b978dffb in QThreadPrivate::start(void*) () from /usr/lib64/qt4/libQtCore.so.4
#3  0x00007f91b94f7e2c in start_thread () from /lib64/libpthread.so.0
#4  0x00007f91b82701dd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f91bac78780 (LWP 14054)):
#0  0x00007f91b8267573 in poll () from /lib64/libc.so.6
#1  0x00007f91b51df796 in g_main_context_iterate.isra.23 () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f91b51df8c4 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f91b98bb1ff in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/qt4/libQtCore.so.4
#4  0x00007f91b8abd5fe in QGuiEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/qt4/libQtGui.so.4
#5  0x00007f91b988adf2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/qt4/libQtCore.so.4
#6  0x00007f91b988b047 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/qt4/libQtCore.so.4
#7  0x00007f91b988fe65 in QCoreApplication::exec() () from /usr/lib64/qt4/libQtCore.so.4
#8  0x00007f91a02ec6d7 in kdemain (argc=5, argv=0x16b9cc0)
    at /var/tmp/portage/kde-base/dolphin-4.9.0/work/dolphin-4.9.0/dolphin/src/main.cpp:89
#9  0x0000000000408a24 in launch (argc=5, _name=0x1683dd8 "/usr/bin/dolphin", args=<optimized out>, 
    cwd=0x0, envc=<optimized out>, envs=<optimized out>, reset_env=false, tty=0x0, avoid_loops=false, 
    startup_id_str=0x1683e30 "janek-pc-sabayon;1344442880;65406;12959_TIME799476433")
    at /var/tmp/portage/kde-base/kdelibs-4.9.0/work/kdelibs-4.9.0/kinit/kinit.cpp:734
#10 0x0000000000409b06 in handle_launcher_request (sock=7, who=<optimized out>)
    at /var/tmp/portage/kde-base/kdelibs-4.9.0/work/kdelibs-4.9.0/kinit/kinit.cpp:1226
#11 0x000000000040a02f in handle_requests (waitForPid=0)
    at /var/tmp/portage/kde-base/kdelibs-4.9.0/work/kdelibs-4.9.0/kinit/kinit.cpp:1419
#12 0x0000000000405a2e in main (argc=2, argv=0x7fff7a1958c0, envp=0x7fff7a195b90)
    at /var/tmp/portage/kde-base/kdelibs-4.9.0/work/kdelibs-4.9.0/kinit/kinit.cpp:1907

Seeing this occasionally in 4.9.1

I can reproduce this pretty reliably. 
What you must do: 

1. Turn nepomuk off in system settings
2. Open dolphin and right click on an indexed folder.
3. Turn nepomuk on again
2. Right click again on an indexed folder.

I got this backtrace: 

hread 5 (Thread 0x7f19e25ec700 (LWP 17987)):
#0  0x00007f19ef4fe073 in select () from /usr/lib/libc.so.6
#1  0x00007f19ecaad430 in ?? () from /usr/lib/libsopranoclient.so.1
#2  0x00007f19ecaaf76a in ?? () from /usr/lib/libsopranoclient.so.1
#3  0x00007f19ecab01b6 in ?? () from /usr/lib/libsopranoclient.so.1
#4  0x00007f19ecab2880 in ?? () from /usr/lib/libsopranoclient.so.1
#5  0x00007f19ecab54d3 in ?? () from /usr/lib/libsopranoclient.so.1
#6  0x00007f19f2109846 in Nepomuk2::MainModel::executeQuery(QString const&, Soprano::Query::QueryLanguage, QString const&) const ()
   from /usr/lib/libnepomukcore.so.4
#7  0x00007f19f20fc710 in Nepomuk2::ResourceData::determineUri() () from /usr/lib/libnepomukcore.so.4
#8  0x00007f19f210fd59 in Nepomuk2::Resource::determineFinalResourceData() const () from /usr/lib/libnepomukcore.so.4
#9  0x00007f19f2110404 in Nepomuk2::Resource::property(QUrl const&) const () from /usr/lib/libnepomukcore.so.4
#10 0x00007f19f211056c in Nepomuk2::Resource::isRelateds() const () from /usr/lib/libnepomukcore.so.4
#11 0x000000000041dd0f in NepomukActivityManager::resourcesLinkedToActivity(QString const&) const ()
#12 0x000000000041df08 in NepomukActivityManager::isResourceLinkedToActivity(KUrl const&, QString const&) const ()
#13 0x0000000000416a93 in Resources::IsResourceLinkedToActivity(QString const&, QString const&) const ()
#14 0x0000000000429ac2 in ResourcesAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
#15 0x0000000000429ceb in ResourcesAdaptor::qt_metacall(QMetaObject::Call, int, void**) ()
#16 0x00007f19f15dfef3 in ?? () from /usr/lib/libQtDBus.so.4
#17 0x00007f19f15e0ff5 in ?? () from /usr/lib/libQtDBus.so.4
#18 0x00007f19f15e1966 in ?? () from /usr/lib/libQtDBus.so.4
#19 0x00007f19f15e1a5b in ?? () from /usr/lib/libQtDBus.so.4
#20 0x00007f19f1279fae in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4
#21 0x00007f19f03f908c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#22 0x00007f19f03fd50a in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#23 0x00007f19f2aa1df6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#24 0x00007f19f12655ee in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#25 0x00007f19f1268f51 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4
#26 0x00007f19f12935b3 in ?? () from /usr/lib/libQtCore.so.4
#27 0x00007f19ebb28475 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#28 0x00007f19ebb287a8 in ?? () from /usr/lib/libglib-2.0.so.0
#29 0x00007f19ebb28864 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#30 0x00007f19f1293746 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#31 0x00007f19f126433f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#32 0x00007f19f12645c8 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#33 0x00007f19f11657c0 in QThread::exec() () from /usr/lib/libQtCore.so.4
#34 0x000000000040ebea in Resources* runInQThread<Resources>()::Thread::run() ()
#35 0x00007f19f116879c in ?? () from /usr/lib/libQtCore.so.4
#36 0x00007f19f0ed8e0f in start_thread () from /usr/lib/libpthread.so.0
#37 0x00007f19ef50445d in clone () from /usr/lib/libc.so.6

Thread 4 (Thread 0x7f19e1be5700 (LWP 17988)):
#0  0x00007f19ef4fc2cd in poll () from /usr/lib/libc.so.6
#1  0x00007f19ebb28744 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f19ebb28864 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f19f1293746 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f19f126433f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#5  0x00007f19f12645c8 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f19f11657c0 in QThread::exec() () from /usr/lib/libQtCore.so.4
#7  0x000000000040ebba in Activities* runInQThread<Activities>()::Thread::run() ()
#8  0x00007f19f116879c in ?? () from /usr/lib/libQtCore.so.4
#9  0x00007f19f0ed8e0f in start_thread () from /usr/lib/libpthread.so.0
#10 0x00007f19ef50445d in clone () from /usr/lib/libc.so.6

Thread 3 (Thread 0x7f19e13e4700 (LWP 17989)):
#0  0x00007f19ef4fc2cd in poll () from /usr/lib/libc.so.6
#1  0x00007f19ebb28744 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f19ebb28864 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f19f1293766 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f19f126433f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#5  0x00007f19f12645c8 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f19f11657c0 in QThread::exec() () from /usr/lib/libQtCore.so.4
#7  0x000000000040eb8a in Features* runInQThread<Features>()::Thread::run() ()
#8  0x00007f19f116879c in ?? () from /usr/lib/libQtCore.so.4
#9  0x00007f19f0ed8e0f in start_thread () from /usr/lib/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#10 0x00007f19ef50445d in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0x7f19d3908700 (LWP 17990)):
#0  0x00007f19ef4fc2cd in poll () from /usr/lib/libc.so.6
#1  0x00007f19ebb28744 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f19ebb28864 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f19f1293766 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f19f126433f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#5  0x00007f19f12645c8 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f19f11657c0 in QThread::exec() () from /usr/lib/libQtCore.so.4
#7  0x00007f19f1244aff in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007f19f116879c in ?? () from /usr/lib/libQtCore.so.4
#9  0x00007f19f0ed8e0f in start_thread () from /usr/lib/libpthread.so.0
#10 0x00007f19ef50445d in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7f19f3568780 (LWP 17986)):
#0  0x00007f19ef4fc2cd in poll () from /usr/lib/libc.so.6
#1  0x00007f19ebb28744 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f19ebb28864 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f19f1293766 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f19f049950e in ?? () from /usr/lib/libQtGui.so.4
#5  0x00007f19f126433f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f19f12645c8 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#7  0x00007f19f1269268 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#8  0x000000000040a725 in main ()

and again with symbols for soprano:

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7f8893820700 (LWP 26686)]
0x00007f88a211331d in write () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007f88a211331d in write () from /usr/lib/libpthread.so.0
#1  0x00007f889dce1b36 in Soprano::Socket::write(char const*, long long) () from /usr/lib/libsopranoclient.so.1
#2  0x00007f889dce23a6 in Soprano::SocketStream::writeUnsignedInt16(unsigned short) () from /usr/lib/libsopranoclient.so.1
#3  0x00007f889dce6830 in Soprano::Client::ClientConnection::executeQuery(int, QString const&, Soprano::Query::QueryLanguage, QString const&) () from /usr/lib/libsopranoclient.so.1
#4  0x00007f889dce94e3 in Soprano::Client::ClientModel::executeQuery(QString const&, Soprano::Query::QueryLanguage, QString const&) const
    () from /usr/lib/libsopranoclient.so.1
#5  0x00007f88a333d846 in Nepomuk2::MainModel::executeQuery(QString const&, Soprano::Query::QueryLanguage, QString const&) const ()
   from /usr/lib/libnepomukcore.so.4
#6  0x00007f88a3330710 in Nepomuk2::ResourceData::determineUri() () from /usr/lib/libnepomukcore.so.4
#7  0x00007f88a3343d59 in Nepomuk2::Resource::determineFinalResourceData() const () from /usr/lib/libnepomukcore.so.4
#8  0x00007f88a3344404 in Nepomuk2::Resource::property(QUrl const&) const () from /usr/lib/libnepomukcore.so.4
#9  0x00007f88a334456c in Nepomuk2::Resource::isRelateds() const () from /usr/lib/libnepomukcore.so.4
#10 0x000000000041dd0f in NepomukActivityManager::resourcesLinkedToActivity(QString const&) const ()
#11 0x000000000041df08 in NepomukActivityManager::isResourceLinkedToActivity(KUrl const&, QString const&) const ()
#12 0x0000000000416a93 in Resources::IsResourceLinkedToActivity(QString const&, QString const&) const ()
#13 0x0000000000429ac2 in ResourcesAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
#14 0x0000000000429ceb in ResourcesAdaptor::qt_metacall(QMetaObject::Call, int, void**) ()

There were two overlapping problems here:

1. Soprano::ClientConnection::isConnected() does not, in fact, check whether a socket is connected, merely whether is has been successfully connected in the past. So when nepomuk is shut down, the resource manager still (falsely) claims it has a valid connection to the server and if anyone tries to write to it, will crash, which is what is happening. 

Reviews https://git.reviewboard.kde.org/r/107283/ and https://git.reviewboard.kde.org/r/107285/ fix this problem by explicitly marking the socket as disconnected when the resourcemanager gets the nepomukstopped signal. One patch is to nepomuk-core and one to kdelibs. 

2. kactivities was testing for the presence of nepomuk by watching for ownership changes to its dbus service. The resourcemanager listens to a specific dbus signal before configuring itself, so the dbus service ownership change will always occur before resourcemanager reconnects to the new nepomuk socket and declares itself ready. This means that kactivities will try to write to the old socket, which no longer exists. 

https://git.reviewboard.kde.org/r/107290/ changes kactivities to listen to the "ready" signal from resourcemanager, avoiding this problem.

Although any one of these patches will fix this specific bug, unless all three are applied, specific corner cases will still fail. Particularly both the kdelibs and nepomuk-core patches are needed, even in 4.10, because of the new kFileMetaDataWidget, which depends on nepomuk from kdelibs, thus making dolphin link to kdelibs' nepomuk.

Git commit 436b31deabd46f3ccd8fa0b7d6ac03e1bcac2948 by Simeon Bird.
Committed on 10/11/2012 at 04:47.
Pushed by sbird into branch 'KDE/4.9'.

Manually disconnect the socket connection to nepomuk in the resourcemanager when
the socket is remote disconnected.

This is needed because the Soprano method isConnected() does not
actually check whether the socket is connected or not.

REVIEW: 107285
FIXED-IN: 4.9.4

M  +5    -0    libnepomukcore/resource/nepomukmainmodel.cpp
M  +10   -0    libnepomukcore/resource/nepomukmainmodel.h
M  +3    -0    libnepomukcore/resource/resourcemanager.cpp

http://commits.kde.org/nepomuk-core/436b31deabd46f3ccd8fa0b7d6ac03e1bcac2948