Tracker has by default a 10s timeout enabled to check for low disk space, so that the miners get paused if reached a threshold. We should probably disable that timeout by default, as we do in Harmattan, as tracker-store can handle those situations gracefully AFAIK. So this is something where we could also improve.

But, that is not the timeout causing the 1s wakeups (no statfs64 calls reported in your logs). And have never seen such situation before either... Anyone has another idea of what could be happening?

(In reply to comment #0)
> tracker-miner-fs wakes up every second if the machine is otherwise idle. It
> shouldn't do that.
> 
> poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, events=POLLIN},
> {fd=12, events=POLLIN}, {fd=9, events=POLLIN}], 5, 995) = 0 (Timeout)
> poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, events=POLLIN},
> {fd=12, events=POLLIN}, {fd=9, events=POLLIN}], 5, 997) = 0 (Timeout)
> poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, events=POLLIN},
> {fd=12, events=POLLIN}, {fd=9, events=POLLIN}], 5, 995) = 0 (Timeout)
> poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, events=POLLIN},
> {fd=12, events=POLLIN}, {fd=9, events=POLLIN}], 5, 995) = 0 (Timeout)
> poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, events=POLLIN},
> {fd=12, events=POLLIN}, {fd=9, events=POLLIN}], 5, 994
> 
> 
> That's the strace output, and goes on like that, over and over and over again.

Is it possible this is related to .xsession-errors?

Other than the 10 second poll for disk space we do (which I am going to disable for today's release), I only get poll events on file changes (like to .xsession-errors). I suspect this is for the FD we use with inotify which sees the updates there.

NOTE, we don't log this and we have code to explicitly reject anything for .xsession-errors because it is constantly changing. This will cause constant wakes of course.

poll doesn't return an FD, it returns due to reaching the roughly 1000 ms timeout, so it can't be caused by inotify.

(In reply to comment #3)
> poll doesn't return an FD, it returns due to reaching the roughly 1000 ms
> timeout, so it can't be caused by inotify.

From what I remember, poll() returns on either a timeout or an input/output on an FD as indicated in the return value. My strace checks here certainly appear to be related to inotify and changes to .xsession-errors:

We're probably seeing a combination of timeouts and actual changes at some point.

--
poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=15, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}], 5, 987) = 1 ([{fd=16, revents=POLLIN}])
ioctl(16, FIONREAD, [48])               = 0
read(16, "\17\0\0\0\2\0\0\0\0\0\0\0 \0\0\0.xsession-errors"..., 1024) = 48
read(16, 0x1b589a0, 1024)               = -1 EAGAIN (Resource temporarily unavailable)
--

The 10 second timeout to check disk space has now been disabled by default in master and will be in today's release 0.12.2.

commit 9486898dca25776dce3f51d7e4b6abed0f8f1ef2
Author: Martyn Russell <martyn@lanedo.com>
Date:   Thu Sep 22 11:34:22 2011 +0100

    tracker-miner-fs: Change default for low-disk-space-limit to be disabled (-1)
    
    This has been done to avoid the poll() call every 10 seconds we have in place
    given the store already has mechanisms in place for handling out of disk
    space.

Is strace (or some test script) writing its logs in a location indexed by tracker? That could explain that tracker is waken up on a regular rhythm.

(In reply to comment #6)
> Is strace (or some test script) writing its logs in a location indexed by
> tracker? That could explain that tracker is waken up on a regular rhythm.

Nope, we learned from that a while ago :P

It's also one of the reasons why we explicitly drop any event about ~/.xsession-errors.

I suspect some of the other wake ups may be related to d-bus, they're at least socket types here according to lsof.

(In reply to comment #4)
> (In reply to comment #3)
> > poll doesn't return an FD, it returns due to reaching the roughly 1000 ms
> > timeout, so it can't be caused by inotify.
> 
> From what I remember, poll() returns on either a timeout or an input/output on
> an FD as indicated in the return value. My strace checks here certainly appear
> to be related to inotify and changes to .xsession-errors:

My strace output I posted shows clearly that poll() returns 0, meaning that it's repeated 1s timeouts that cause the wakeups, not inotify, or anything else.

A quick check with strace doesn't show this issue here. I suspect that it's related to bug 659479, the busy loop issue. E.g., there is a one second timeout for "Waiting for event pairs", which is not used when miner-fs is idle.

The current default config does not wake up at all frequently and strace is quiet.

As Aleksander says in comment #1, we do check every 10 seconds if configured to check frequently.

We could certainly improve the way we do the disk space check (e.g. on events for file changes)?

I would like to approach this entirely differently actually. I would like a central process to manage these sort of resource checking and maintaining tasks. This could have a simple inotify check on the DB and do a check on each DB update or 60 seconds (which ever is longest). Something like that anyway.

Lennart, if you have a better idea, I am all ears! :)

Tracker has accumulated a few substantial changes in these last ~4y.

Lennart, is this something you still see?

I consider this fixed.