| Summary: | Strigi decides to ignore existing database after reboot. | ||
|---|---|---|---|
| Product: | [Unmaintained] nepomuk | Reporter: | Chuck <cfox04> |
| Component: | general | Assignee: | Sebastian Trueg <sebastian> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bigbrovar, blackr2d, foolecho, jonasrj20, kde, snvv101, trueg, uwe.helms |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Chuck
2010-08-21 20:29:04 UTC
I was searching through bguzila looking whether this has been filed before when I found yours. strigi would just for some reason decide to stop working even though its running and indexing in the background any query via dolphin returns a zero result I was searching through bguzila looking whether this has been filed before when I found yours. strigi would just for some reason decide to stop working even though its running and indexing in the background any query via dolphin returns a zero result Unfortunately I am able to confirm this on Gentoo x86_64, KDE 4.5.2. It happens not every time, but when it happens sometimes I am able to see the file count (in the window that appears when clicking on the systray) moving down until reaching zero. Seems to be a 4.5 regression. Virtuoso is 6.1.2, KDE is 4.5.2, soprano 2.5.2 Fuchs This bug should closely related with https://bugs.kde.org/show_bug.cgi?id=226895 Confirming on Gentoo X86 and KDE 4.5.4 Had to use zfs with timed snapshots for nepomuk virtuoso db. It seems that's not a DB corruption as if that happens (strigi ignores old entries and starts to index again) and I have a DB from a snapshot just before the bug and restart whole nepomuk on it - there's no problem. It seems pretty random. *** Bug 254468 has been marked as a duplicate of this bug. *** Experiencing this bug on Arch Linux (kernel 3.1) with KDE 4.7.3 as well. Even if Strigi had successfully ended initial indexing before reboot, and after reboot Nepomuk reports to have the files in the index (according to total number of files), Strigi (re)starts initial indexing again. Upon finishing indexing, unless I created some, no new files have been added to the index (total number of files unchanged). Indexing takes the same amount of time, 1st, 2nd, 3rd, ... time. Also, even though Nepomuk is reporting to have files in it's index, searching in Dolphin yields no results before indexing finishes again. I noticed these lines on the terminal when closing down my KDE-session: startkde: Shutting down... klauncher: Exiting on signal 1 startkde: Running shutdown scripts... ProcessControl: Application '/usr/bin/nepomukservicestub' stopped unexpected (Process crashed) Application '/usr/bin/nepomukservicestub nepomukfilewatch' crashed. No restart! [...] ProcessControl: Application '/usr/bin/nepomukservicestub' stopped unexpected (Process crashed) Application '/usr/bin/nepomukservicestub nepomukstorage' crashed. No restart! (These lines are there every time: I started looking for them) Could (some part of) nepomuk crashing when KDE is ending the session be a part of the problem? Or is it normal for it to crash like this....? I can confirm the behavior described by Jonas (I'm also under Archlinux and Kde 4.7.3 ^^) and bring some other elements for confirmation: - in spite of nepomuk indexes, strigi reindexes from scratch not only at startup of Kde but each time strigi is manually stopped then launched during the session although the indexation was previously over (so I don't think about a problem with a nepomuk crash on shutdown: I've nothing related to that in my session log, by the way) - the bug was not present in kdelibs in 4.7.2 and doesn't appear with downgrading.(In reply to comment #7) Do not confuse indexing with scanning for changes for which there simply is no technical solution at the moment. |