On Fri, 2017-12-01 at 13:50 +0100, Carlos Garnacho wrote:
We don't constantly crawl anything, at least on purpose :).
That was what I {sus,ex}pected but wanted to be sure my assumption was
correct.
Tracker does no special treatment of NFS mounts,
But it does not have the benefit of things like inotify so it must have to crawl periodically, mustn't it?
In the case there is no monitoring (disabled, run out of handles, ...)
Or NFS?
tracker-miner-fs would simply crawl it once on startup to check mtimes and reindex the content updated since the last index.
Does it not want to re-index changed/updated files since the startup crawl/index?
And as it's been pointed out, Tracker uses glib file monitors, which have a FAM implementation. However, the limits are checked on Tracker by looking up the file monitor created on $HOME.
So it has to be one file monitor for all filesytems? It cannot choose different/best file monitor based on what kind of filesystem it's trying to monitor.
Back to why it's stuck in that state... do you see cpu activity
Yes. Lots: 3260 tty2 SNl+ 12033:31 /usr/libexec/tracker-miner-fs
or anything in logs from tracker-miner-fs
Only a cluster of: Nov 25 14:26:25 pc.interlinx.bc.ca dbus-daemon[2489]: [session uid=1001 pid=2489] Activating via systemd: service name='org.freedesktop.Tracker1.Miner.Extract' unit='tracker-extract.service' requested by ':1.95' (uid=1001 pid=3260 comm="/usr/libexec/tracker-miner-fs " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
or tracker-store?
Lots of clusters of: Dec 01 04:55:09 pc.interlinx.bc.ca tracker-store[3383]: Could not create FTS delete statement: table fts5 has no column named nco:hobby but they don't really align with the repeated crawling activity.
Please file a bug, and we get going from there.
https://bugzilla.gnome.org/show_bug.cgi?id=791085 Cheers, b.
Attachment:
signature.asc
Description: This is a digitally signed message part