On Sun, 2017-04-16 at 13:41 +0100, Sam Thursfield wrote:
Hi Chris On 4/15/17, Chris <cpollock 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/rWpuwgEJSorry for the lack of responses about this. I think this error occurs when the tracker-miner-fs tries to insert duplicate information for files that are already in the store. That's why the error says "UNIQUE constraint failed": the nie:url table enforces that there's only one entry for a given URL, so the duplicate insert is rejected. This error is mostly harmless, but obviously it's bad that Tracker is wasting energy trying to insert duplicate entries to the database and filling your syslog with junk. I've seen this before but I don't know what causes it. I guess we need to add more diagnostics to tracker-miner-fs so that it gives more useful error output; it's the sort of problem that never occurs when you're actually in a position to actually debug it. It's possibly a compatibility issue caused when upgrading from one version of Tracker to another ... (our automated tests don't cover that at all at present sadly). I hate recommending this but I think that removing the database and recreating it will fix. If you don't have important data saved in your Tracker database try `tracker reset --soft`, and if that doesn't fix, `tracker reset --hard`. There appears to be no bug for this already in Bugzilla, so please file one if you can. And thanks for contributing to Tracker! Sam
I tried both --soft and --hard reset. I still get what's shown on the pastebin link below and my syslog is now syslog 350415273 in size, well it's huge! So large that in fact postfix refuses to send my hourly syslog snippets to me because the file is too large. After running either soft or hard I did a restart, I assume I had to do that. Here's the link to the paste - https://pastebin.com/EKG6V4cm Question is though I'm seeing the same output to syslog when I just do a system restart that I do when I run 'tracker reset -e or -r and then a restart is tracker trying to rebuild the database each and every time I do a system restart? If so that does seem like an awful waste of resources. Since I installed tracker 1.12.0 from source after this bug was fixed h ttps://bugzilla.gnome.org/show_bug.cgi?id=779342 (Thanks Carlos for the quick response to this, Ubuntu Gnome folks still haven't provided the fix for download). I 'assume' that since I haven't had any more issues with the problem in the bug I can safely say that I'm running 1.12.0 instead of the Ubuntu version apt-cache policy tracker tracker: Installed: 1.6.2-0ubuntu1.1 Candidate: 1.6.2-0ubuntu1.1 Version table: *** 1.6.2-0ubuntu1.1 500 As you can see below my load average is super high which is right after the restart and all the tracker processing. If I've left something out or I misunderstood something please let me know. I'm not quite sure how to word the title of the bug report. Something like 'When tracker is restarted after a system restart it attempts to completely rebuild the database'? Should I also report the same bug in Ubuntu? As I noted above I've still not seen a fix trickle down from the one Carlos made the same day as I reported it. Thanks Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 14:17:46 up 5 min, 1 user, load average: 7.28, 6.00, 2.85 Description: Ubuntu 16.04.2 LTS, kernel 4.4.0-72-generic
Attachment:
signature.asc
Description: This is a digitally signed message part