Temporarily disable file indexing - Pause miner vs. removing/re-adding folder

Platform
1

Hey there,

For context, I have a script that (re-)generates several thousands of ODT and PDF files based on some template ODT files, starting with deleting the old ones. In practice, most generated files will quite often end-up being exactly the same as the previous ones (e.g. same hash, same modification date).

I noticed localsearch is consuming a tremendous amount of resources during and after this process, which is not surprising considering the amount of files deleted and then generated.

So I thought I’d somehow temporarily disable file indexing while the script is running. Since most files end-up being the same, I assumed pausing the Files miner would be the way to go. I was expecting that once it’s resumed, it would notice that only a few files have changed and quickly re-index these.

cookie=$(localsearch daemon --miner "Files" --pause "the reason" | grep "Cookie is" | grep -Eo '[0-9]+')

localsearch daemon --miner "Files" --resume "$cookie"

However, after being resumed, localsearch actually still consumes a tremendous amount of resources, contrary to what I was expecting.

I tried another approach: to entirely remove the top parent folder from the index while the script is running and then add it again. I was expecting this would require at least as many resources, since localsearch would have to delete and recreate from scratch the entire index for this folder.

localsearch index -d ~/the_top_parent_folder

localsearch index -a -r ~/the_top_parent_folder

Surprisingly, it uses several orders of magnitude less resources than the pause/resume approach!

Is there any reason? Is it because maybe, once resumed, the miner actually has to inspect every file in each and every indexed folder to check if it has changed? If that’s the case, I guess having the ability to pause the miner for a given indexed folder (or even better, for a specific path) would be the most optimal option.

PS: I struggled a bit to figure out how to pause/resume the miner which is mainly why I posted my commands, in case other people might find it useful. FYI, the command line documentation mentions an inhibit command which doesn’t seem to exist. As for the localsearch-daemon man page, it mentions a -l option which doesn’t seem to exist either.

2

Hi,

The inhibit subcommand was added in LocalSearch 3.9.0. The documentation is updated from the main branch, and reflects the existing options there. You seem to have a too old version for those commands (I assume you use a Debian derivative, with LocalSearch 3.8.x), the currently supported stable branch is two cycles ahead (3.10.x).

Regarding your usecase, the elephant in the room is that Poppler is the black sheep of LocalSearch dependencies. It fits the bill from a pragmatic perspective (we want PDF files indexed), but it is not a library designed for fast metadata extraction, and is by a big margin the slowest metadata extractor. We are looking for alternatives to it.

There may be two factors to what you are seeing:

  • At the moment, when the indexer is inhibited, file monitors do still work, and even though there will be some merging of events (e.g. the usual business with temporary files is detected), file changes will generally be queued up, to be flushed after unhibitting. I have plans to change this behavior so nothing gets queued up, but instead a check over all indexed folders is issued after uninhibit (in order to detect any possible changes), but there’s tradeoffs as usual.
  • I am not sure how are you measuring this, but it is possible a chunk of the activity you are missing happens on localsearch index --delete instead of localsearch index –add. Being thousands of documents I assume text-heavy. With SQLite Full-Text Search, unindexing text is as expensive an operation as inserting it. All (to be) indexed text has to be tokenized, and every individual token accounted for, either added or removed. A document file update is from that perspective a remove+add operation, so twice the work at once.

But I’m just speculating, this is the stuff that debug logging and sysprof might be thrown at. You might also experiment with localsearch daemon –terminate + localsearch daemon –start, or by creating the documents in a non-indexed folder (e.g. hidden folder), and moving to the final location.

If you didn’t want the documents indexed, I’d recommend creating a .nomedia file on that folder, but I assume that’s not what you want.

3

Thanks Carlos for the very comprehensive answer!

The inhibit subcommand was added in LocalSearch 3.9.0.

Indeed, I’m on Ubuntu 25.10 running v3.8.2, thanks for the clarification.

when the indexer is inhibited, file monitors do still work […], file changes will generally be queued up, to be flushed after unhibitting

Indeed, I think that explains why localsearch consumes as many resources after it’s resumed compared to before I disabled file indexing.

I am not sure how are you measuring

Just monitoring the localsearch-3 process and checking how much CPU it’s using.

  1. In case I remove/re-add the top parent folder from/to the index:
    1. Removing takes less than a couple of seconds
    2. Re-adding is also a matter of a few seconds
  2. In case I pause/resume the miner:
    1. Pausing doesn’t seem to use any resource at all (I’m guessing not enough to pop up)
    2. Resuming is a matter of minutes

Being thousands of documents I assume text-heavy

Luckily, these are all 1-pagers :wink:

You might also experiment with localsearch daemon –terminate + localsearch daemon –start

These commands don’t seem to exist in v3.8, I’ll definitely have a look once Ubuntu upgrades to a more recent version. As well as the future behavior of when the indexer is inhibited.

or by creating the documents in a non-indexed folder (e.g. hidden folder), and moving to the final location.

Thanks for the advice. Though this might not change much, since the original files would be overwritten with the new ones. In any case, I’m currently quite happy with the remove/re-add option.

If you didn’t want the documents indexed, I’d recommend creating a .nomedia file on that folder, but I assume that’s not what you want.

Indeed :wink:

4

My bad, they are not referenced in the v3.8.2 man page but they do exist. And they definitely do the trick, i.e. overall localsearch-3 barely seems to use any resource at all. Thanks for the tip!

Only drawback: when those two commands are invoked in a quick succession (even from the command line), the --start command raises an error (and as a result, the miner isn’t running):

$ localsearch daemon --terminate
Found 1 PID…
  Killed process 440126 — “localsearch-3”
$ localsearch daemon --start
Starting miners…

(tracker daemon:441504): Tracker-CRITICAL **: 09:45:22.021: Could not get miner progress for 'org.freedesktop.Tracker3.Miner.Files': GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/freedesktop/Tracker3/Miner/Files”
  ✗ File System (perhaps a disabled plugin?)
$ localsearch daemon
Miners:
29 oct. 2025, 09:46:58:  ✗     File System          - Not running or is a disabled plugin

Should I create an issue to report this behavior?

NB: it appears that the localsearch deamon command has been removed in the more recent versions, but there are still references to it in the documentation sections of:

5

I went ahead and reported the issue on the Gnome bug tracker:

[v3.8.2] Error when invoking daemon –terminate and --start in a quick succession

I also submitted it to the Ubuntu bug tracker;

Error when invoking daemon –terminate and --start in a quick succession Edit

Not sure if it also happens with more recent versions, but in case Ubuntu sticks with the v3.8 branch for a while, a fix could hopefully get released for that branch :crossed_fingers:

6

Following the feedback from @sthursfield, a workaround for the Tracker-CRITICAL issue is to stop/start the daemon using:

  • systemctl --user stop localsearch-3.service
  • systemctl --user start localsearch-3.service