+mnissler, dcheng

I doubt my https://codereview.chromium.org/2236523002/ is guilty since it only landed in master and removes dead code.

With that said, I've experienced the opposite issue myself before: if I have Chrome open with a lot of tabs and try to use another program that tries to obtain inotify handles, the latter often fails because the maximum limit of inotify instances (the fs.inotify.max_user_instances sysctl aka /proc/sys/fs/inotify/max_user_instances) has been reached. I then need to either close Chrome or become root and raise the limit. I suspect this is related to the fact that InotifyReader is leaking its handles as discussed in  bug 636346 .

Perhaps the issue you're getting is caused by another program exhausting the inotify handle limit before you launch Chrome.

I don't think Chrome is leaking inotify instances. I haven't verified, but I believe we create exactly one inotify instance per Chrome process that makes use of FilePathWatcher. We don't free that instance explicitly, but it should be reclaimed by the OS when the process dies.

It'd be helpful if someone running into this problem could check what consumes all the inotify instances. A command like this should help cast some light:

ls -l /proc/*/fd/* 2>/dev/null | grep inotify | sed -nre 's!^.*(/proc/([0-9]+)/fd/([0-9]+)).*$!\1 \2 \3!; T; p' | while read path pid fd; do echo "$path $(cat /proc/$pid/cmdline 2>/dev/null | tr '\0' ' ')"; done

This displays the FDs for processes with open inotify instances. On my system, there are two inotify instances consumed by Chrome (both in the browser process). Not sure why there are two (maybe some library uses inotify in addition the chrome code?), but these two wouldn't explain exhaustion.

Sorry for the FUD, I didn't check the code in depth and didn't notice Chromium was very spartan in its use of inotify handles.

At the moment, running that command you suggested returns /opt/google/chrome/chrome 5 times (2 of which with --type=service). Most of the handles belong to /usr/bin/krunner, so KDE may be leaking handles (or just using them too much).

I raised fs.inotify.max_user_watches from 8192 to 1000000 and still see the same message (no other symptoms, though).

Oh, duh, raising fs.inotify.max_user_instances instead fixes this for me.

It looks like Sublime Text (tested: 3128) likes to use a lot of inotify instances.

Archiving old bugs that haven't been actively assigned in over a year.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!