Bug 232398 - nepomukservices/strigi desktop search systray module should report when nepomukservices/strigi crashed to often
Summary: nepomukservices/strigi desktop search systray module should report when nepom...
Status: RESOLVED FIXED
Alias: None
Product: nepomuk
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Trueg
URL:
Keywords:
: 232814 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-27 22:27 UTC by Martin Steigerwald
Modified: 2013-06-10 13:11 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Steigerwald 2010-03-27 22:27:46 UTC
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.
Comment 1 Martin Steigerwald 2010-03-27 22:55:58 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. ;)
Comment 2 Martin Steigerwald 2010-03-28 16:00:35 UTC
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.
Comment 3 Martin Steigerwald 2010-03-31 20:44:51 UTC
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.
Comment 4 Sebastian Trueg 2011-01-06 20:13:09 UTC
*** Bug 232814 has been marked as a duplicate of this bug. ***
Comment 5 bosyber 2011-12-30 13:25:04 UTC
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.
Comment 6 Martin Steigerwald 2012-01-04 10:46:43 UTC
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.
Comment 7 reescf 2012-01-09 04:22:36 UTC
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.]
Comment 8 bosyber 2012-01-11 08:46:30 UTC
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
Comment 9 Vishesh Handa 2013-06-10 13:11:36 UTC
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.