inotify watches limit in karmic is too low ( /proc/sys/fs/inotify/max_user_watches )

Bug #408981 reported by Martin Olsson
94
This bug affects 5 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Medium
Unassigned
Nominated for Karmic by Martin Olsson
Nominated for Lucid by Martin Olsson
procps (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Karmic by Martin Olsson
Nominated for Lucid by Martin Olsson

Bug Description

When I start the application "monodevelop" on karmic it says that karmic's default "maximum inotify watches limit" (i.e. /proc/sys/fs/inotify/max_user_watches ) is too small for it to work optimally. Karmic currently allows 8192 inotify watches and monodevelop needs at least 9000 to function properly. The warning printed by monodevelop looks like this:

  WARNING [2009-08-04 20:26:15Z]: Inotify watch limit is too low (8192).
  MonoDevelop will switch to managed file watching.
  See http://www.monodevelop.com/Inotify_Watches_Limit for more info.

The URL mentioned in the warning has some good info on this issue. I believe it reverts to another, sub-optimal, method (probably some nasty form of polling or so) for notifications when the limit is as low as it is by default in Ubuntu. This means that MonoDevelop consumes more resources than necessary on Ubuntu.

Unless there are good arguments against it, I suggest karmic changes it "maximum allowed inotify watches" to a higher value (I suppose SuSE etc uses 16K since that's what the MonoDevelop guys recommend) to fix this problem.

Tags: kj-triage
Revision history for this message
Martin Olsson (mnemo) wrote :

Looks like "/etc/sysctl.conf" ships in the "procps" package. Maybe that's a better package for this bug?

Revision history for this message
Diego Schulz (dschulzg) wrote :

Programs linked against Qt 4.5.2 are also complaining about inotify issues.
When instantiating some classes (ie. QPrintDialog) I see:

QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Success
QFileSystemWatcher: failed to add paths: /home/dschulz

I tried raising /proc/sys/fs/inotify/max_user_watches to 16384 (from 8192) with no effect at all.
Also tried raising /proc/sys/fs/inotify/max_user_instances to 512 (from 128) with no effect.

I noticed inotify problems after upgrading from 2.6.31-4 to 2.6.31-5. It looks like a regression in the kernel.

visibility: public → private
visibility: private → public
Revision history for this message
Diego Schulz (dschulzg) wrote :

I recently noticed inotify_add_watch() system call always returns 0

(assuming fd1 has a valid descriptor returned by inotify_init() )

    if((wd1 = inotify_add_watch(fd1,path1, IN_OPEN | IN_ACCESS | IN_ATTRIB)) < 0)
        perror("inotify_add_watch failed");

    fprintf(stderr, "wd1= %d\n", wd1 );

This piece of code always prints "wd1= 0".

Revision history for this message
Diego Schulz (dschulzg) wrote :

Installed 2.6.30-2 and the problem disappears. Alas, inotify_add_watch() returns 1 (not 0) in the same conditions I tried in 2.6.31-5. This is definitely an upstream issue in the 2.6.31-5 kernel.

Revision history for this message
Diego Schulz (dschulzg) wrote :

Apparently this issue is causing pulseaudio to crash, but I don't have enough time to investigate more.

Let's hope inotify stuff will get fixed in the next rc kernel.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

The default limit comes from the kernel, and if it is to be raised, it should raise there. We should not set defaults in userspace with sysctl

Changed in procps (Ubuntu):
status: New → Invalid
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-triage
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Martin Olsson (mnemo) wrote :

Current Lucid with 2.6.32-16-generic kernel suffers from the same bug.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Martin,
    Thank you for following up. Are you aware of whether this has been raised with the kernel maintainers upstream? We prefer for most fixes to come from them if possible.

Thanks!

~JFo

Revision history for this message
Martin Olsson (mnemo) wrote :

I tried it with 2.6.34-020634rc1-generic mainline vanilla kernel now and that suffers from the bug as well. I also posted a questions to the MonoDevelop mailing list asking why they need _thousands_ of inotify watches for a single app:
http://lists.ximian.com/pipermail/monodevelop-list/2010-March/011451.html

Revision history for this message
Chase Douglas (chasedouglas) wrote :

The value is hardcoded into the Linux kernel [1], though it can be changed through a sysctl. Since the value is hardcoded without any configuration option for increasing it, it probably isn't meant to be increased for a normal distribution. A discussion of the proper value or configuration parameter should probably be brought up on the linux-fsdevel mailing list. We likely would only accept such a change coming from upstream, as we prefer to keep the Ubuntu kernel in sync with the upstream kernel as much as possible.

For these reasons, I'm marking this bug as "Won't Fix".

[1] http://lxr.linux.no/linux+v2.6.33/fs/notify/inotify/inotify_user.c#L822
[2] http://vger.kernel.org/vger-lists.html#linux-fsdevel

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.