Hi Chris, On Tue, Feb 28, 2017 at 3:50 PM, Chris <cpoll...@embarqmail.com> wrote: > On Tue, 2017-02-28 at 11:23 +0100, Carlos Garnacho wrote: >> Hi, >> >> On Mon, Feb 27, 2017 at 6:52 PM, Chris <cpoll...@embarqmail.com> >> wrote: >> > >> > The complete notation to my syslog that I'm seeing every two >> > minutes >> > every hour, every day is: >> > >> > Feb 27 11:44:33 localhost tracker-extract.desktop[3603]: (tracker- >> > extract:3603): dconf-CRITICAL **: unable to create file >> > '/run/user/1000/dconf/user': Permission denied. dconf will not >> > work >> > properly. >> > Feb 27 11:46:42 localhost tracker-extract.desktop[3603]: message >> > repeated 2 times: [ (tracker-extract:3603): dconf-CRITICAL **: >> > unable >> > to create file '/run/user/1000/dconf/user': Permission >> > denied. dconf >> > will not work properly.] >> >> I've noticed this warning across reported logs since the >> tracker-extract process was sandboxed. I suspect this is related to a >> sandboxed thread accessing gsettings, although it's most clearly not >> tracker itself, since all tracker-extract settings are read on >> startup >> and in-memory representation is accessible readonly to the extractor >> threads. >> >> So this could be some tracker module that is trying to poke GSettings >> underneath, but I'm entirely unclear which. If anyone can get me >> backtrace of that specific warning (eg. setting up >> G_DEBUG=fatal-criticals in tracker-extract environment), that'd be >> appreciated. >> >> That said, the warning should be harmless, at least if I'm right. >> >> Cheers, >> Carlos >> > Hi Carlos, someone suggested, I think it was on the list, that an X > process is changing the permission of /run/user/1000/dconf/user every 2 > minutes. I find that very hard to believe that could happen especially > since the only process I have that continuously wakes every 2 minutes > if fetchmail and it's not an X process. I can open Gnome terminal and > see that the timestamp -rw------- 1 chris chris 2 Feb 28 08:42 user is > the same as when I go to check it with the ls -l command. IOW I'm > beginning to agree with you now that I don't think the permissions are > being changed but tracker thinks they are. Does that sound about > right?
That is precisely what I think is happening. Inside the sandboxed bits, open() with write permissions is disallowed altogether, I think something is attempting to read settings inside the sandbox which in turn tries to open that file with readwrite permission. I've only seen this warning recently in recent bug reports, and always tied to tracker-extract. On second read of gsettings/dconf code, it seems possible that file descriptors are reloaded behind our back, so it sounds plausible that it is tracker-extract after all, I'm doing a patch that I think should fix these warnings. > > Since I'm retired and don't have much else to do except tend to my > plants and go to doctors appointments at the VA I'll give setting up > the backtrace you need a try if you can point me to a good how-to. I'll try to make the patch available upstream asap, so hopefully Ubuntu will pick it up soon. If you anyway want to get into this trouble :), here's some steps: 1) you need gdb installed, and hopefully tracker debuginfo packages so the backtrace has more sense 2) in a terminal do: tracker daemon -t 3) in another terminal do: G_DEBUG=fatal-criticals gdb /usr/lib/tracker/tracker-extract 4) in the gdb prompt, do 'r' (shortcut for "run"), tracker-extract will run as usual 5) back in the first terminal, do: tracker daemon -s 6) get on with your normal activity 7) when the warning is hit (assuming it's the first one you'll get), gdb will be back to its prompt, you can do "t a a bt" to get the backtrace for all threads (what I ask for), or you can tell it to continue with 'c'. Please do file a bug to bugzilla.gnome.org with this information. Cheers, Carlos _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
