tracker doesn't leave any for the rest of the class

Confirmed here too. I spent a few hours trying to solve an issue whereby one of my development projects that uses inotify couldn't add new watches. I checked the maximum limits but couldn't find a way to get inotify to report a list of the watches so in the end gave up on it.

Like Scott I have a *lot* of directories configured in two trees (Projects/ and SourceCode)/. SourceCode has copies of the source of about a hundred packages I have debugged or inspected and in addition the complete kernel, l-u-m and l-r-m trees for Feisty, Gutsy and kernel.org.

The quick fix is to increase number of inotify watch limit by default to 64,000 or something high

this should be a bug against the kernel or boot config though rather than tracker

short term fix :
echo 65565 > /proc/sys/fs/inotify/max_user_watches

long term: apply to a boot up script

For hardy, I will attempt to write a kernel patch to generate a persistent ring buffer log file of all file changes which can be used by user space apps instead of watches - this would dramatically increase startup as no crawling of directories to place watches on them would be needed

Jamie: this isn't an invalid bug -- as you point out, it's either a bug in tracker for blithely consuming all instances, or a kernel bug for inotify being crap in the first place.

Since you are working on a kernel patch, I've opened a task for that and assigned it to you

Jamie,

That sounds great! I've been pretty peeved about inotify:s lack of built-in recursive directory monitoring. A ring buffer of all file changes would solve that one automatically... and the max_user_watches problem to boot. :)

Only hope you can get it accepted upstream...

("this would dramatically increase startup"... I assume you meant to say decrease :)

Workaround instructions to put it in a bootscript. Place
  fs.inotify.max_user_watches=20000
in /etc/sysctl.conf

Just For Info

The ring-buffer approach is not going to be accepted. First off, a list of files that have changed is useless. The full path does not accomodate symlinks or hardlinks. Secondly, we don't want users being able to see all the files that have changed. That's a data leak that exposes security concerns.

Closing kernel task, as there seems to be no real solution for the kernel. Using sysctl to increase the default (since the default is supposed to be safe) seems like the only sane idea.

Unlikely a fix would be applied to 2.6.22/gutsy even if one was developed.

If the kernel won't fix it, then this is a bug in tracker

tracker (0.6.4) leaves 500 inotify watches free - is that enough?

marking as fixed in 0.6.4