Strigi uses an uncontrollable, monotonically growing, amount of space that cannot be reclaimed

Bug #642652 reported by Sergio Callegari
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kdebase (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: kdebase

The actual bug is "that cannot be reclaimed".

Scenario. Multiuser system. Each user has a kde desktop. Strigi is enabled by default with (IMHO) very silly defaults about what to index. Result: after a few months, each user has a > 3GB space wasted with the strigi indexing information. Either the machine comes low with disk space in home and nobody cannot work anymore, or users come low with disk space wrt their quotas and most of them cannot work anymore. Users start complaining since they cannot understand why they are low on disk, since given the actual things they had put in their home, all of them think that they should have a few GB left.

You tell them that it is the indexer. They tell you that they do not use it. You tell them that maybe they do not use it, but still it is working. They ask you why you do not disable it by default. You tell them that there is no documentation saying how to create users' skeleton environments with strigi disabled. They tell you "ok, I gonna disable it from my system settings". Finally most of them do so (either by disabling strigi completely or by telling strigi to index only much more selected stuff).

For the remaining users you need to find out on your own where the strigi configuration file is to disable it from there. Otherwise, there is no way for "root" to run "systemsetting" to configure the environment of one of his users without knowing the user password and logging in to the kde environment as the user, which seems a rather intrusive thing to do.

Ok, finally you have strigi disabled for everybody. What is the result? Absolutely nothing. When you tell strigi either not to index files at all (or not to index directory XXX), the space used for indexing (or at least for indexing directory XXX) is not reclaimed at all.

You go on google, and the hint is to kill the whole nepomuk database for each user. It is quite lucky that most users had never ever used nepomuk tags and ontologies at all. Otherwise they would get quite upset at seeing them wiped away.

Please... given that nepomuk had already costed european taxpayers over 11.500.000 EUR (15 M$), make a little extra effort to have a little "reclaim space" or "clean database" button, as databases that monotonically increase in space are not exactly nice.

In the meantime, please kubuntu, let strigi be disabled for all users as a sane default. Users who know what it is for will also know how to enable it and how to deal with its quirks.

Revision history for this message
Alessandro Ghersi (alessandro-ghersi) wrote :

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. While we appreciate your issue, it would be better if it was tracked at https://bugs.kde.org, so that the KDE developers can deal with this speedily and have direct communication with you as the reporter for more effective debugging.

Thanks!

Changed in kdebase (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.