Version: (using KDE 4.4.1) OS: Linux Installed from: Debian testing/unstable Packages As described in detail in bug #232395 nepomukservices/strigi seems to choke on some file and crashes too often. Then either the systray icon which I can click to get the status of the scanning does not respond or is silently removed. Expected result: It should notify the user that nepomukservices/strigi crashed too often and bail out nicely. I think it should offer to report a bug and to deactive strigi desktop search altogether on such an incident.
Well strigi service is deactivated in the desktop search KCM after such a too often crash has happened. Still the user should be informed about this. And I think it should already report when the first crash happens. For me right now it appears that a crash is seen as a something usual to happen, when Nepomuk tolerates 4 or 5 crashes before giving up restarting nepomuk strigi service. A crash is a crash and should be fixed IMHO. ;)
Strigi service is only deactivated till the next login. If it chokes on a file I think it would be approbiate to either exclude that file from the next scan or to disable strigi service completely - the user should be notified and asked. There is no point running into the same crash again and again.
In bug #232814 Michael Schuerig made similar suggestions on how to handle a file crashing bug in Nepomuk: Currently, Nepomuk just restarts strigi and starts over from the beginning. Instead it would be much better to - Notify the user that a file is causing problems. - Exclude this file from indexing as long as it remains unchanged. - Resume indexing after the offending file.
*** Bug 232814 has been marked as a duplicate of this bug. ***
Is there anything I can do to help resolve this bug faster? Recently I had a harddisk crash, and perhaps not all files restored perfectly well - I have an .xsession-errors log of about 135MB now, all messages about this, and nepomuk keeps trying without any other sign, apart from a certain amount of background activity. Quite inconvenient, as potentially the error condition could otherwise be used to locate the misbehaving file, allowing it to be replaced with a better version from a backup.
Well for me Nepomuk as of merkaba:~> apt-show-versions | egrep "(streamanalyzer|soprano|nepomuk|virtuoso)" libnepomuk4/experimental uptodate 4:4.7.4-1 libnepomukquery4a/experimental uptodate 4:4.7.4-1 libnepomukutils4/experimental uptodate 4:4.7.4-1 libsoprano-dev/experimental uptodate 2.7.3+dfsg.1-1 libsoprano4/experimental uptodate 2.7.3+dfsg.1-1 libstreamanalyzer0/sid uptodate 0.7.7-1 soprano-daemon/experimental uptodate 2.7.3+dfsg.1-1 virtuoso-minimal/wheezy uptodate 6.1.3+dfsg1-2 virtuoso-opensource-6.1-bin/wheezy uptodate 6.1.3+dfsg1-2 virtuoso-opensource-6.1-common/wheezy uptodate 6.1.3+dfsg1-2 is working rock stable for me. I did not experience any crashes. Its generating some debug - I have 22 MiB in xsession-errors, but it is not only that - output like: [/usr/bin/nepomukservicestub] virtual Soprano::ODBC::Connection::~Connection() Soprano::Server::ServerConnection(0x7f7054 004e10) [/usr/bin/nepomukservicestub] void Soprano::Server::ServerCore::serverConnectionFinished() virtual Soprano::Server::ServerConnection::~ServerConnection() Removing connection [/usr/bin/nepomukservicestub] void Soprano::Server::ServerCore::serverConnectionFinished() Connection removed. Current co unt: 13 also I disabled debug output in kdebugdialog - well Nepomuk isn´t KDE only. But I think the amount of debug output really should be covered by a different bug report. This one is about crash reports and reporting of on which file it crashed. So please open up a different bug report regarding debug output - if not already done by someone else. Thanks.
How can I determine whether it is crashing or not? I don't have "crash" in ~/.xsession-errors but nepomukservices/strigi does seem to keep starting again and again and again. Surely it wouldn't keep re-indexing the same things if it wasn't crashing? It seems to start from scratch every time I log in (usually after restarting the computer) and sometimes at other times. I assume this is because it is giving up and never completing although I'm not sure what to check... [And although it is a different issue, my ~/.xsession-errors is huge and part of that is complaints from strigi about non-utf8/latin1 strings.]
Yes, Martin (comment#6) I agree that adressing the amount (and manner) of debug output should be subject to a different bug report (and yes, I really should create that report soon), I only mentioned it because it made determining what was wrong harder in this case. As for the crash: I too now have it rock solid too, after deleting the .kde nepomuk folders and rebuilding the db, so it is possibly a corrucpt db that caused it. But I do think an important issue to resolve is how nepomuk recovers from such a crash - it shouldn't just try again and again without success (in the process creating a lot of redundant debug messages). bouke@syblap:~$ apt-show-versions | egrep "(streamanalyzer|soprano|nepomuk|virtuoso)" libnepomuk4/oneiric uptodate 4:4.7.4-0ubuntu0.1~ppa2 libnepomukquery4a/oneiric uptodate 4:4.7.4-0ubuntu0.1~ppa2 libnepomukutils4/oneiric uptodate 4:4.7.4-0ubuntu0.1~ppa2 libsoprano4/oneiric-updates uptodate 2.7.4+dfsg.1-0ubuntu0.1 libstreamanalyzer0/oneiric uptodate 0.7.6-2ubuntu1 soprano-daemon/oneiric-updates uptodate 2.7.4+dfsg.1-0ubuntu0.1 virtuoso-minimal/oneiric uptodate 6.1.3+dfsg1-1ubuntu1 virtuoso-nepomuk/oneiric uptodate 6.1.3+dfsg1-1ubuntu1 virtuoso-opensource-6.1-bin/oneiric uptodate 6.1.3+dfsg1-1ubuntu1 virtuoso-opensource-6.1-common/oneiric uptodate 6.1.3+dfsg1-1ubuntu1
Partly fixed with 4.10 - We have a much better indexing framework. The situation has improved even more with 4.11 where we have even better error handling.