[kdepim-users] How to disable mail indexing with Akonadi search
Sandro Knauß
sknauss at kde.org
Sun Feb 7 18:41:35 GMT 2016
Hey,
okay the history is, that there ws nepomuk. With the switch to baloo the whole
mail indexing and rest of baloo was divided. So in baloo it was handeled in
the same repo but had nothing in common with baloo itself. Okay it used the
same db like baloo (xapian). With kf5 baloo switch to some other db that is
better usable for file indexing. But because the projects don't have anything
in common, the repo was devided into baloo and akonadi-search.
> Back in Baloo times it was easy to disable mail indexing. But with Akonadi
> Search which as I understand is basically a renamed Baloo for mail stuff I
> didn´t find a way yet. Can one disable it?
You find the settings for akonadi_indexing_agent in .config/akonadi/
agent_config_akonadi_indexing_agent. But there is not much :( To disable it you
can use akonadiconsole. But I think it is marked as autoinstall by a desktop
file: /usr/share/akonadi/agents/akonadiindexingagent.desktop
So the next time akonadi is started the indexer ist started by default. You
have to overwrite this setting. Or deinstall akonadi-search this is possible
in debian :) There are complains, that it isn't installed by default...
>
> I excluded the biggest folders yet it still crawls Akonadi to a halt with at
> least 90-100% CPU load on mysqld for tenth of minutes or more up to the
> point where something happens that doesn´t happen with Akonadi + KDEPIM
> from master otherwise since all the performance improvements: KMail looses
> connection to Akonadi and is unusable unless I restart it.
Well if it akonadi-search hitting the mysql means that it is indexing mails,
so you need a first run, if everything is indexed this schould not happen
anymore.
> Also currently the mail index would grow to big that BTRFS gets into trouble
> with free space, up to kernel 4.3 even freezing up the whole machine with a
> kworker thread searching for free space (known issue in BTRFS, that may or
> may not be fixed in 4.4 or later).
>
> For now at least for the storage thing I did:
>
> touch ~/.local/share/akonadi/search_db
>
> then akonadi indexing agent does not create a directory there and no space
> is used up.
>
> As you know my mail setup is a bit crazy, so I know the index is big, but
> still after 5 GiB I keep wondering whether it needs to be that big,
> especially as I excluded at least the folders with LKML mails.
>
> For now until I have more free SSD space I just want to disable it.
>
> I help myself with repeating
>
> killall /home/kde/install/bin/akonadi_indexing_agent
>
> until Akonadi gives up starting the indexing agent after each time I start
> Akonadi by logging into a Plasma session or restarting it after a new
> compile from master.
>
> Also with indexing "disabled" like this Akonadi doesn´t auto complete
> anything in to address field. Not even from address book which is quite
> annoying. Only from recent addresses, but this is only mail addresses not
> the Name <mail at address> form I prefer.
Well the autocompetion is done via akonadi-search (there is another db) that
stores the mailadresses. It crawls through the addressbook and all mails and
make these available via autocompletion. So no akonadi-search -> no
autocompletion. So disable akonadi-search completly you loose that feature.
> So is there a way to just tell it not to indexing *any* mail? I think such
> an option is still important and if its just for people with low free disk
> space.
Not at the moment.
> So or so I get the impression since Baloo mail indexing has been renamed to
> Akonadi search and put into Akonadi repo no one really looked into it
> anymore. In KDE SC 4.14 times it really worked good. It still works fine on
> my KDE SC 4.14 based KDEPIM on the workstation at works. So I am a bit sad
> that it again is broken for me.
Well yes, akonadi-search don't get much love at the moment, but also was not
really much improved before. But in kde4 times this was hidden by the baloo
changes - now it is possible to see in git easily that nearly nothing is
happing. On the other side, akonadi-search is working very well. If you don't
have space problems and a intial db. The most problems with search were
located in other parts of kdepim...
Regards,
sandro
More information about the kdepim-users
mailing list