Summary: | nepomukservices/strigi desktop search systray module should report when nepomukservices/strigi crashed to often | ||
---|---|---|---|
Product: | nepomuk | Reporter: | Martin Steigerwald <Martin> |
Component: | general | Assignee: | Sebastian Trueg <sebastian> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | benoitg, bosyber, me, michael, reescf, sven.burmeister |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Martin Steigerwald
2010-03-27 22:27:46 UTC
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. |