Re: [Tracker] Tracker-CRITICAL
Hi Chris, On Fri, Sep 22, 2017 at 3:48 AM, Chris wrote: > Tracker version 1.10.0 - I've run tracker daemon -k which killed all > the processes but if the below continues I'd just as soon permanently > disable it. How can that easily be done? You can remove the dbus service files from /etc/xdg/autostart. > > Sep 21 20:00:04 localhost gnome-session[3498]: (tracker-miner-fs:3745): > Tracker-CRITICAL **: (Sparql buffer) Error in task 0 > (file:///home/chris/Downloads) of the array-update: UNIQUE constraint > failed: nie:DataObject.nie:url (strerror of errno (not necessarily > related): Resource temporarily unavailable) > Sep 21 20:00:04 localhost gnome-session[3498]: (tracker-miner-fs:3745): > Tracker-CRITICAL **: Could not execute sparql: UNIQUE constraint > failed: nie:DataObject.nie:url (strerror of errno (not necessarily > related): Resource temporarily unavailable) > > Hundreds of the above lines are written to syslog whenever I do a > restart. There is https://bugzilla.gnome.org/show_bug.cgi?id=786132 trying to cover all conditions that might lead to this misbehavior. Feel free to chime in there, it would be great that you provided the output of "tracker info ~/Downloads" so that I have a better understanding of why does this happen to you. Cheers, Carlos ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
[Tracker] Tracker-CRITICAL
Tracker version 1.10.0 - I've run tracker daemon -k which killed all the processes but if the below continues I'd just as soon permanently disable it. How can that easily be done? Sep 21 20:00:04 localhost gnome-session[3498]: (tracker-miner-fs:3745): Tracker-CRITICAL **: (Sparql buffer) Error in task 0 (file:///home/chris/Downloads) of the array-update: UNIQUE constraint failed: nie:DataObject.nie:url (strerror of errno (not necessarily related): Resource temporarily unavailable) Sep 21 20:00:04 localhost gnome-session[3498]: (tracker-miner-fs:3745): Tracker-CRITICAL **: Could not execute sparql: UNIQUE constraint failed: nie:DataObject.nie:url (strerror of errno (not necessarily related): Resource temporarily unavailable) Hundreds of the above lines are written to syslog whenever I do a restart. -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 20:26:14 up 34 min, 1 user, load average: 0.67, 0.52, 0.86 Description:Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic signature.asc Description: This is a digitally signed message part ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] TRACKER-Critical
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 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 signature.asc Description: This is a digitally signed message part ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] TRACKER-Critical
On Sun, 2017-04-16 at 16:41 -0500, Chris wrote: > On Sun, 2017-04-16 at 13:41 +0100, Sam Thursfield wrote: > > > > Hi Chris > > > > On 4/15/17, Chris 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 > > > > > Sorry 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 > > > Usually I have 5 tracker process shown running when I run pgrep > tracker: > > chris@localhost:/var/log$ pgrep tracker > 4709 > 4710 > 4717 > 4723 > 4725 > > Coming back a few hours later after that last restart I find when > checking the tracker processes I only have one: > > pgrep tracker > 8424 > > Since I assume that the daemon has not restarted for some reason I > run > tracker daemon which outputs: > > tracker daemon > Store: > 16 Apr 2017, 16:28:29: ✓ Store - Idle > > Miners: > 16 Apr 2017, 16:28:29: ✗ Extractor - Not running or > is > a disabled plugin > 16 Apr 2017, 16:28:29: ✗ Userguides- Not running or > is > a disabled plugin > 16 Apr 2017, 16:28:29: ✗ Applications - Not running or > is > a disabled plugin > 16 Apr 2017, 16:28:29: ✗ File System - Not running or > is > a disabled plugin > > And if trying to start the daemon: > > tracker daemon start > Store: > 16 Apr 2017, 16:34:06: ✓ Store - Idle > > Miners: > 16 Apr 2017, 16:34:06: ✗ Extractor - Not running or > is > a disabled plugin > 16 Apr 2017, 16:34:06: ✗ Userguides- Not running or > is > a disabled plugin > 16 Apr 2017, 16:34:06: ✗ Applications - Not running or > is > a disabled plugin > 16 Apr 2017, 16:34:06: ✗ File System - Not running or > is > a disabled plugin > > So, do I have to restart the system again to see if tracker will > start? > I imagine by now you're getting tired of hearing from me. However, I have more questions and I apologize for not understanding what's going on. In my last post, quoted above, everything except tracker store was not running or disabled. Instead of restarting the system I logged out and back in again to see if the daemon would restart. It apparently did and again started filling up syslog. Prior to logging out and back in however before doing that I set --set-log-verbosity=debug. I logged out and back in and some output is here - https://pastebin.com/tEi4V0tQ als o this includes other information. I've changed the verbosity back to 'errors' will log out and back in again and see what happens this time. Now I'm back to the output to syslog as before Apr 16 12:04:14 localhost gnome-session[3500]: (tracker-miner-fs:3721): Tracker-CRITICAL **: Could not execute sparql: UNIQUE constraint failed: nie:DataObject.nie:url (strerror of errno (not necessarily related): Resource temporarily unavailable) Apr 16 12:04:14 localhost gnome-session[3500]: (tracker-miner-fs:3721): Tracker-WARNING **: File 'file:///home/chris/Downloads/tracker-1.12.0' has been reenqueued more than 2 times. It will not be indexed. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 16:59:50 up 2:47, 2 users, load average: 1.29, 2.63, 2.43 Description:Ubuntu 16.04.2 LTS, kernel 4.4.0-72-generic signature.asc Description: This is a digitally signed message part ___
Re: [Tracker] TRACKER-Critical
On Sun, 2017-04-16 at 13:41 +0100, Sam Thursfield wrote: > Hi Chris > > On 4/15/17, Chris 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 > > > Sorry 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 > Usually I have 5 tracker process shown running when I run pgrep tracker: chris@localhost:/var/log$ pgrep tracker 4709 4710 4717 4723 4725 Coming back a few hours later after that last restart I find when checking the tracker processes I only have one: pgrep tracker 8424 Since I assume that the daemon has not restarted for some reason I run tracker daemon which outputs: tracker daemon Store: 16 Apr 2017, 16:28:29: ✓ Store - Idle Miners: 16 Apr 2017, 16:28:29: ✗ Extractor - Not running or is a disabled plugin 16 Apr 2017, 16:28:29: ✗ Userguides- Not running or is a disabled plugin 16 Apr 2017, 16:28:29: ✗ Applications - Not running or is a disabled plugin 16 Apr 2017, 16:28:29: ✗ File System - Not running or is a disabled plugin And if trying to start the daemon: tracker daemon start Store: 16 Apr 2017, 16:34:06: ✓ Store - Idle Miners: 16 Apr 2017, 16:34:06: ✗ Extractor - Not running or is a disabled plugin 16 Apr 2017, 16:34:06: ✗ Userguides- Not running or is a disabled plugin 16 Apr 2017, 16:34:06: ✗ Applications - Not running or is a disabled plugin 16 Apr 2017, 16:34:06: ✗ File System - Not running or is a disabled plugin So, do I have to restart the system again to see if tracker will start? -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 16:18:15 up 2:06, 1 user, load average: 0.25, 0.20, 0.13 Description:Ubuntu 16.04.2 LTS, kernel 4.4.0-72-generic signature.asc Description: This is a digitally signed message part ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] TRACKER-Critical
On Sun, 2017-04-16 at 13:41 +0100, Sam Thursfield wrote: > Hi Chris > > On 4/15/17, Chris 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 > > > Sorry 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 signature.asc Description: This is a digitally signed message part ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] TRACKER-Critical
Hello Carlos, On 16 April 2017 at 17:47, Carlos Garnacho wrote: > Hi Jose! > > 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= > 900636b2bfe5b91175e521a4acd2296216eb52b0 > fixing this. > > Thanks for the heads up! > Carlos > No problem, happy to help. Yeah, we talked about this some time ago over IRC. It's been a while since I came around here ^^. Chris's log files reminded me of an issue I came across. I think I had somewhat similar results at the time, I described the issue in https://bugzilla.gnome.org/show_bug.cgi?id=772570 but I don't think it fits Chris' scenario. Cheers, Jose ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] TRACKER-Critical
Hi Jose! On Sun, Apr 16, 2017 at 9:58 AM, Jose Arroyo 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/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. 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=900636b2bfe5b91175e521a4acd2296216eb52b0 fixing this. Thanks for the heads up! Carlos ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] TRACKER-Critical
Hi Chris, First of all, sorry for the lack of responses. I personally had a quite busy past weeks with gnome release, other core components requiring attention, and several hackfests/conferences. I overall had very little attention span left for Tracker, so sorry it caught you in between... Let me encourage you to join the #tracker channel at gnome IRC servers for questions like this. I can get more easily sidetracked over there :), so the response time could be hopefully measured in minutes/hours rather than days/weeks. On Sat, Apr 15, 2017 at 5:25 PM, Chris 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 This is about the last recurrent warning I know about in Tracker. It is harmless (the file is already inserted in the database, just that tracker-miner-fs tries to insert it again, everything else will work alright with the already inserted information) , but unfortunately I don't know of any reliable reproduction steps. These warnings happen long after the real error (i.e. tracker-miner-fs had to deem the file as "needs (re)indexing" during initialization, which is the prerequisite to have the file indexed at all) If you have any idea about how you got into that situation, please do file a bug describing the steps to reproduce, they are most welcome. Thanks, Carlos ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] TRACKER-Critical
On Sun, 2017-04-16 at 13:41 +0100, Sam Thursfield wrote: > Hi Chris > > On 4/15/17, Chris 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 > > > Sorry 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 > Thanks for the reply Sam, I will submit the bug report and give your fix a try also. Actually, I'm not in the habit of using Tracker at all. I've not delved into its workings so far. I'll get back to you and the list when all is done. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 07:47:58 up 10:37, 1 user, load average: 0.28, 0.37, 0.41 Description:Ubuntu 16.04.2 LTS, kernel 4.4.0-72-generic signature.asc Description: This is a digitally signed message part ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] TRACKER-Critical
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 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
Re: [Tracker] TRACKER-Critical
Hi Chris On 4/15/17, Chris 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 > Sorry 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 ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
[Tracker] TRACKER-Critical
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 signature.asc Description: This is a digitally signed message part ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
[Tracker] Tracker-CRITICAL **: Could not execute sparql
Can someone explain what is causing this? It appears to have happened when I restarted the system this afternoon and again after a kernel update. The restart happened the first time because I've been out of town for a few days. There was a power outage and the system didn't come back up. Here is snippets of both times it happened - https://pastebin.com/Mdhiq mxJ Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 18:05:04 up 2:45, 1 user, load average: 0.39, 0.31, 0.35 Description:Ubuntu 16.04.2 LTS, kernel 4.4.0-72-generic signature.asc Description: This is a digitally signed message part ___ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Tracker-Critical error in the tracker-miner-fs.log
Hello Martyn, With the mentioned commit it works fine. I am able to generate the log for every re-start. Thanks, John On Wed, Sep 7, 2011 at 2:18 PM, Martyn Russell wrote: > On 07/09/11 06:50, John stacy wrote: > >> Hello Team, >> > > Hello, > > > I am using tracker-0.10.18 on my ubuntu mechine. For this version, I >> added few g_debug messages and installed the tracker. >> After restarting the ubuntu mechine, I am able to observe the complete >> log messages in the tracker-miner-fs.log file for the first time. >> >> Again If I restart the tracker using the below commands >> # tracker-control -r >> # tracker-control -s >> >> I am facing dbus-critical error and after this message the logging stops >> i.e there are no log messages available further, though the tracker >> executes fine. >> *06 Sep 2011, 22:09:29: Tracker-Critical **: Couldn't create new Files >> miner: 'D-Bus service name:'org.freedesktop.**Tracker1.Miner.Files' is >> already taken, perhaps the application is already running?'* >> >> why am I getting this error? >> is there any other way of starting the tracker apart from the above >> commands? >> > > There is a race condition where the miner is instantiated more than once at > the same time. That leads to this error. Jürg fixed this in master (the logs > being overwritten) yesterday and it will be in the 0.10.26 release tomorrow. > > See commit b74b7df2f685bd3e693341c7092467**19a1ba9849 > > > How to get the log messages in the tracker-miner-fs file after the >> second restart? (My current verbosity level in all configuration files >> are 3) >> > > You will either have to patch by cherry-picking that commit above or wait > for 0.10.26 unfortunately (unless you want to use master). > > > I am unable to understand the after effects of commenting out the above >> mentioned critical error in the source code >> (*src/miners/fs/tracker-miner-**files-index.c *and >> *src/libtracker-miner/tracker-**miner-object.c*) as my main goal is to >> get >> the complete log for miner for every restart. >> > > Yea, this one has bugged me for a while, it should be fine now. > > -- > Regards, > Martyn > > Founder and CEO of Lanedo GmbH. > ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Tracker-Critical error in the tracker-miner-fs.log
On 07/09/11 06:50, John stacy wrote: Hello Team, Hello, I am using tracker-0.10.18 on my ubuntu mechine. For this version, I added few g_debug messages and installed the tracker. After restarting the ubuntu mechine, I am able to observe the complete log messages in the tracker-miner-fs.log file for the first time. Again If I restart the tracker using the below commands # tracker-control -r # tracker-control -s I am facing dbus-critical error and after this message the logging stops i.e there are no log messages available further, though the tracker executes fine. *06 Sep 2011, 22:09:29: Tracker-Critical **: Couldn't create new Files miner: 'D-Bus service name:'org.freedesktop.Tracker1.Miner.Files' is already taken, perhaps the application is already running?'* why am I getting this error? is there any other way of starting the tracker apart from the above commands? There is a race condition where the miner is instantiated more than once at the same time. That leads to this error. Jürg fixed this in master (the logs being overwritten) yesterday and it will be in the 0.10.26 release tomorrow. See commit b74b7df2f685bd3e693341c709246719a1ba9849 How to get the log messages in the tracker-miner-fs file after the second restart? (My current verbosity level in all configuration files are 3) You will either have to patch by cherry-picking that commit above or wait for 0.10.26 unfortunately (unless you want to use master). I am unable to understand the after effects of commenting out the above mentioned critical error in the source code (*src/miners/fs/tracker-miner-files-index.c *and *src/libtracker-miner/tracker-miner-object.c*) as my main goal is to get the complete log for miner for every restart. Yea, this one has bugged me for a while, it should be fine now. -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
[Tracker] Tracker-Critical error in the tracker-miner-fs.log
Hello Team, I am using tracker-0.10.18 on my ubuntu mechine. For this version, I added few g_debug messages and installed the tracker. After restarting the ubuntu mechine, I am able to observe the complete log messages in the tracker-miner-fs.log file for the first time. Again If I restart the tracker using the below commands # tracker-control -r # tracker-control -s I am facing dbus-critical error and after this message the logging stops i.e there are no log messages available further, though the tracker executes fine. *06 Sep 2011, 22:09:29: Tracker-Critical **: Couldn't create new Files miner: 'D-Bus service name:'org.freedesktop.Tracker1.Miner.Files' is already taken, perhaps the application is already running?'* why am I getting this error? is there any other way of starting the tracker apart from the above commands? How to get the log messages in the tracker-miner-fs file after the second restart? (My current verbosity level in all configuration files are 3) I am unable to understand the after effects of commenting out the above mentioned critical error in the source code (*src/miners/fs/tracker-miner-files-index.c *and *src/libtracker-miner/tracker-miner-object.c*) as my main goal is to get the complete log for miner for every restart. Thanks, John ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
