Version: (using Devel) OS: Linux Installed from: Compiled sources KDE 4.2 Beta 1 (kde-neon nightly) on Kubuntu and same error on OpenSuse 11.0 KDE 4.2 beta1): Strigi desktop file indexer is enabled in Desktop Search - System Settings but gives the following error message and indexing doesn't work: Failed to contact Strigi indexer (No such method 'currentFolder' in interface 'org.kde.nepomuk.Strigi' at object path '/nepomukstrigiservice' (signature ''))
strigi probably crashed. Please try installing strigi from current svn trunk. It contains some fixes that are not released.
Thanks, Sebastian. Strigi did in fact crash. I reinstalled it from the current svn and it keeps crashing. These are the messages from the the kernel log (they appeared after several different attempts): [ 1260.593619] strigidaemon[8161]: segfault at 0 ip 08086d3a sp b543dea0 error 4 in strigidaemon[8048000+a3000] 2008-11-27 14:31:53 strigidaemon[11070] segfault at 0 ip 08086d3a sp b52aeea0 error 4 in strigidaemon[8048000+a3000] 2008-11-27 17:53:37 strigidaemon[15455] segfault at 0 ip 08086d3a sp b5427ea0 error 4 in strigidaemon[8048000+a3000] Enabling strigi in System Settings>Nepomuk/Strigi Configuration doesn't seem to do anything: it says "strigi service not running" after the change applied. I can start the daemon and indexing from strigiclient manually and it looks like it's working judged by the strigidaemon CPU usage in System Monitor and hard disk activity, but no files are indexed and it invariably crashes with the above error. I no longer see the original error message though.
ok, strigidaemon is not used by nepomuk. Please run "nepomukservicestub nepomukstrigiservice" in gdb and get me a backtrace. Thus, we can find the bug (which is probably in strigi)
Sorry, I had to figure out how to use gdb. Gdb produced the following output and then just hung there, nothing happened. I run backtrace after that. (gdb) file nepomukservicestub Reading symbols from /usr/bin/nepomukservicestub...(no debugging symbols found)...done. (gdb) run nepomukstrigiservice Starting program: /usr/bin/nepomukservicestub nepomukstrigiservice (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 0xb65436d0 (LWP 4900)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type <return> to continue, or q <return> to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (gdb) bt #0 0xffffe422 in __kernel_vsyscall () #1 0xb6bc718b in poll () from /lib/libc.so.6 #2 0xb6a676f2 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0xb6a679d8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #4 0xb7f34208 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #5 0xb7689885 in ?? () from /usr/lib/libQtGui.so.4 #6 0xb7f0814a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #7 0xb7f0830a in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #8 0xb7f0a9a5 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #9 0xb75f06a7 in QApplication::exec () from /usr/lib/libQtGui.so.4 #10 0x0804adee in _start () (gdb) Quit A new error message appeared in Nepomuk/Strigi Configuration in System Settings under Strigi, apparently as a result of my attempt to start nepomukstrigiservice from gdb: Failed to contact Strigi indexer (No such method 'currentFolder' in interface 'org.kde.nepomuk.Strigi' at object path '/nepomukstrigiservice' (signature ")) Please let me know if this was what you wanted me to try and if there is anything else I can do.
Well I can confirm that this issue still exists in kde 4.2 beta 2 (4.1.85) on opensuse. I get the same error message in the nepomuk kcm. No indexing seems to be ever happening.
It would be good to have a backtrace with enabled debugging symbols: "cmake -DCMAKE_BUILD_TYPE=Debug"
I've never used gdb before. This is what I get when running nepomukservicestub nepomukstrigiservice. I hope this is what you want. #0 0x00007f1bc60b032f in poll () from /lib64/libc.so.6 #1 0x00007f1bc573a748 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007f1bc573aa6b in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x00007f1bc8da34ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #4 0x00007f1bc812a97f in ?? () from /usr/lib64/libQtGui.so.4 #5 0x00007f1bc8d799a2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #6 0x00007f1bc8d79b2d in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #7 0x00007f1bc8d7bffd in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #8 0x0000000000403851 in main (argc=2, argv=0x7fffd127e1d8) at /usr/src/debug/kdebase-runtime-4.1.85/nepomuk/servicestub/main.cpp:149
it is a good start. But could you please run it again, let it crash, and then execute: thread apply all bt
OK, so this is the output I'm getting (which is the same as before as far as I can tell) : Thread 1 (Thread 0x7f059d582750 (LWP 18700)): #0 0x00007f059a3e632f in poll () from /lib64/libc.so.6 #1 0x00007f0599a70748 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007f0599a70a6b in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x00007f059d0db4ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #4 0x00007f059c46297f in ?? () from /usr/lib64/libQtGui.so.4 #5 0x00007f059d0b19a2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #6 0x00007f059d0b1b2d in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #7 0x00007f059d0b3ffd in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #8 0x0000000000403851 in main (argc=2, argv=0x7fffa55b64b8) at /usr/src/debug/kdebase-runtime-4.1.87/nepomuk/servicestub/main.cpp:149
hm, how did you start this? Via "gdb nepomukervicestub" and then "run nepomukstrigiservice"?
well the problem with that particular method is that I needed to hit ctrl+C to be able to get a backtrace. So basically, gdb nepomukervicestub, then set args nepomukstrigiservice, then run, and then ctrl+c and then thread apply all bt . The other way I did it is to run nepomukervicestub nepomukstrigiservice, than run gdb using the corresponding PID. That way didn't require me to hit ctrl+c. I merely followed the instructions on techbase. If you have a better way of doing it, I'll be happy to try.
I thought it crashed. That would mean: just wait for it to crash.
Created attachment 29971 [details] snapshot of nepomuk kcm
well the thing is it doesn't crash. It just won't work. Attached is what t I see in the nepomuk kcm when nepomukservicestub nepomukstrigiservice is running.
So that is the backtrace you get when the kcm does show that message?
yes. I get the same backtrace whether I run nepomuk in gdb and hit ctrl+c or I run gdb while nepomukstrigiservice is running (in which case no need to hit ctr+c)
that is the exact same thing. In both cases you interrupt the process. That does not help at all. You need to let it crash or freeze. If the service is running properly (ie. is initialized) the backtrace should be much longer. Anyway, maybe you could try using 4.2 rc1
That's what I figured, but the problem is that it won't crash or freeze. I left it running yesterday for several hours and nothing happened, it was still running. However I get the error message right away. I should also add that enabling strigi in the kcm does not work. If I close systemsettings and restart it, it is still disabled. I unfortunately don't have time to compile rc1 at the moment. I will just wait for my distro's packages which should come within the next couple days.
I managed to fix the issue by deleting the config files and the nepomuk folder in .kde4 (don't know why I didn't do it in the first place). So as far as I'm concerned, this issue is fixed.
I can confirm this bug in KDE 4.1.96. Tested under OpenSUSE 11.1 and Fedora 10 (using packages from http://kde-redhat.sf.net). Both fresh installs. It doesn't appear that anything is crashing, I can start `nepomukservicestub nepomukstrigiservice` in a terminal and I get the same error message as in the original report. Deleting configuration files did not work in either case.
I cannot reproduce this problem. The DBUs interface does contain the method in question. This could have happened in the past if an old version of the strigi service was combined with a new version of the kcm. But in 4.2 everything fits together. Is it possible that the packages are somehow messed up?
Created attachment 30496 [details] F10 package versions corresponding to Comment #20 Output of `rpm -qa | sort | grep -e kde -e strigi -e nepo -e redland -e sesame -e soprano` for Fedora 10. Responding to Comment #21 in response to Comment #20
This problem occurred for me with OpenSUSE 11.1 / KDE 4.1.96, and has persisted after upgrade to 4.2 It may be relevant that I started with 11.0, upgraded to 11.1, then added Factory::KDE4 to the repos list to upgrade to 4.1.96 and 4.2 I'm guessing there may be some portion of the infrastructure left un-updated? I'll re-install from scratch some time, if the solution to this isn't unearthed first.
I confirm the bug still persist with a Fedora 10 fresh installed and KDE 4.2 from kde-redhat.
What caused this problem for me was having KDE-Base-Runtime in a different prefix than Strigi, so it couldn't find strigiindex_sopranobackend.so or any of the other KDE-provided plugins (as cmake programs tend to do, it enforces that the install path and search path are the same). Setting STRIGI_PLUGIN_PATH appropriately fixed things up, but the error message was very confusing.
SVN commit 924690 by trueg: Check if the strigi service is initialized which it is not in case plugins could not be loaded properly. Question is: should a service which cannot be initialized be shut down or should there be an error popup? BUG: 176233 M +1 -0 CMakeLists.txt M +20 -14 nepomukserverkcm.cpp M +2 -0 nepomukserverkcm.h WebSVN link: http://websvn.kde.org/?view=rev&revision=924690
I still get the same error. Sorry, but I don't understand what the fix is.