Hello Chris, It's been a while since I've dived into Tracker so my comments may not be terribly useful.
It seems that whenever I reboot my Ubuntu 16.04.2LTS box I get a huge > hourly syslog snippet with what I've put pastebin: At a first glance, those traces seem to show that Tracker is trying to re-index everything after a reboot. I think that this may be triggered by some config option but it may be something else. In any case, the "UNIQUE constraint failed: nie:DataObject.nie:url" error means that the SPARQL query that is used to update the file's entry in Tracker's DB is trying to insert a second url the the file's entry as if it wasn't there. It then fails because there is a constraint to a single url per file. Then you have the logs of this kind: "(tracker-miner-fs:3725): Tracker-WARNING **: File 'file:///home/chris/Downloads/fetchmail-6.4.0.beta2/trio' has been reenqueued more than 2 times. It will not be indexed." The way the Tracker DB is organized, an element is not inserted in the DB unless its parent is already inserted in the DB. So if for some reason, file://foo/bar is being queued for insertion before file://foo, it'll be re-queued for insertion after file://foo is inserted. However, if for some reason, the insertion of file://foo fails, this mechanism will start looping. There is a counter to prevent these infinite loops which is why you get these logs that say that item X won't be indexed because it has already been reenqueued too many times. This whole behavior is somewhat harmless and, as Sam says, might be fixed by reindexing the whole thing from scratch. In any case, what I think is going on boils down to 3 things: - Something is triggering a re-indexation of already indexed directories on reboots (does it also happen if you just stop and start the tracker miner fs?). Is it limited only to your "Downloads" directory? - Something makes Tracker to try and index found files as if they weren't already present in the DB (maybe something wrong with the file last modified check/comparison and the held values in Tracker's internal file system cache?). This causes the SPARQL insert queries to fail consistently. - The reenqueue mechanism triggers the reinsertion of many directories, which continue to fail consistently and thus output a large amount of error logs. Btw, for the Tracker maintainers, there has been for some time a missing g_object_unref() when a file to be reenqueued is dropped ( https://git.gnome.org/browse/tracker/tree/src/libtracker-miner/tracker-miner-fs.c#n2134). They are ref'd when item_reenqueue() is called, but they are never unref'd if the reenqueue'ing isn't actually done. This causes those files to get permanently stuck in Tracker's filesystem cache. Cheers, José M Arroyo On 15 April 2017 at 22:25, Chris <cpoll...@embarqmail.com> wrote: > I've asked about this several times and have received, that I'm aware > of, no replies. Not even one saying 'don't worry about it'. If a bug > report is necessary I'd be happy to submit one. Here is what the latest > shows in my syslog (please ignore other than the pertinent entries). > > https://pastebin.com/rWpuwgEJ > > Chris > > -- > Chris > KeyID 0xE372A7DA98E6705C > 31.11972; -97.90167 (Elev. 1092 ft) > 15:20:40 up 1:11, 1 user, load average: 1.42, 1.39, 0.83 > Description: Ubuntu 16.04.2 LTS, kernel 4.4.0-72-generic > > _______________________________________________ > tracker-list mailing list > tracker-list@gnome.org > https://mail.gnome.org/mailman/listinfo/tracker-list > >
_______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
