On Sun, 2017-04-16 at 12:47 -0300, Carlos Garnacho wrote:
Hi Jose! On Sun, Apr 16, 2017 at 9:58 AM, Jose Arroyo <jose.m.arroyo.se@gmail. com> wrote: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/tra cker-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.Oops, you are right. IIRC you brought this up over IRC but then went forgotten... I've just pushed https://git.gnome.org/browse/tracker/commit/?id=900636b2bfe5b91175e52 1a4acd2296216eb52b0 fixing this. Thanks for the heads up! Carlos _______________________________________________
After reading through a bunch of posts on the Ubuntu list in a thread I started asking how to tell which version of a program is running. I did this because I was attempting to figure out whether the Ubuntu 1.6* version was running or the 1.12.0 version I installed from source was running and to figure out which one was causing the issues I've been asking about and that I submitted the bug report for. After reading through all the posts I decided to take take one suggestion and go with it. What I did was to: sudo apt purge tracker sudo apt autoremove Which removed the 1.6* version completely AFAICT. I then reinstalled the 1.12.0 version just to make sure I have everything needed. Restarted the system and immediately as soon as the boot was done started monitoring syslog. I also ran tracker daemon status which gave the output here - https://pastebin.com /YsZa7WNA my only other issue besides what's shown in the paste is that I now have to manually start tracker. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 20:16:22 up 9 min, 1 user, load average: 0.67, 2.69, 1.94 Description: Ubuntu 16.04.2 LTS, kernel 4.4.0-72-generic
Attachment:
signature.asc
Description: This is a digitally signed message part