The article is moved to https://youtrack.jetbrains.com/articles/IDEA-A-2/Inotify-Watches-Limit
Hi - any idea where I'd find sysctl.conf in IntelliJ 10 (Community Edition) installed on Ubuntu?
It is a system file, not an IDEA one.
Whoops! Thank you
FYI: this solution does not seem to work under CentOS not sure what the correct fix is at this point.
OK, should have looked first, here's the procedure for CentoOS
Sorry, but what's the difference? You just increased the limit to over 5 million (5,242,881 instead of proposed 524,288). Is there any point to set the limit that high?
Considering the following situation: 10 developers work on the working copies, mounted via sshfs from a single server. Don't ask me why, it's not my call.
Should I adjust this settings on developers' working stations and also on server with the value 10 times as big?
Though I've never tried it over sshfs but I'm pretty sure it won't work. Network-mounted FS don't produce file change notifications.
On Fedora, and I suspect other Linux OSes too, the correct solution is not to edit /etc/sysctl.conf but rather to create a new file in /etc/sysctl.d such as "/etc/sysctl.d/idea.conf" and place the config line there.
Sysctl.d is more for packages. It's ok to place user-configured settings in sysctl.conf.
Speaking of packages, it would be nice to have one.
Meanwhile I'd also put the change into a separate file under /etc/sysctl.d .
I'm not telling not to do, just saying sysctl.conf is quite a correct way too.
Also, at least on Fedora 23, sysctl -p doesn't reload the settings. You need to do this instead:
systemctl restart systemd-sysctl.service
In ubuntu 12+, you needn't edit the sysctl.conf file. Just do
sudo sysctl fs.inotify.max_user_watches=xxxxx
This updates the entry in /proc/sys/fs/inotify/max_user_watches but does not seem to modify the /etc/sysctl.conf file.
Right, but it will last only until reboot.
Yup. True that. Modified sysctl.conf (like I should have in the first place!) and it worked like a charm.
I don't understand why it is necessary to set up this limit so high. And it not a good thing to give such a hight value as the must-do in a wiki !
I f you google a little bit, you'll find that the memory used by inotify is 540 * nb of watches on 32bit systems and so 1080 on 64bit ones. 524288 * 1080 = 566 231 040 => 540MiB only for that !
Stackoverflow suggest to count your files to give you a closer idae of how much you really need. I done wih only 92000 max watches on my 8Go source dir .
The links provided clearly say that unused watches does not take any memory.
For Arch Linux users, this solution won't work after version 207 according to this news. But the news also give a work around.
Following for the lazy people:
# vi /etc/sysctl.d/99-sysctl.conf
Then add the line mentioned above:
fs.inotify.max_user_watches = 524288
Or you can just:
# echo "fs.inotify.max_user_watches = 524288" >> /etc/sysctl.d/99-sysctl.conf
# sysctl -p
While running sysctl -p on Arch Linux I got:
sysctl: cannot open "/etc/sysctl.conf": No such file or directory
The correct command seems to be:
# sysctl -p /etc/sysctl.d/99-sysctl.conf
Arch Linux Wiki - sysctl: https://wiki.archlinux.org/index.php/Sysctl#Configuration
When writing settings in the
files, then you should load them via
sudo sysctl --system
sudo sysctl -p
With no parameters is looking directly for the specific /etc/sysctl.conf file.
Have a nice day,
After version 207 SYSTEMD no longer reads from "/etc/sysctl.conf". It reads from "etc/systctl.d/##-sysctl.conf" Where ## means any number 01-99.
Similarly to what has been suggested above for Arch Linux, also on Debian systems (like Ubuntu) one should not modify /etc/sysctl.conf, but create a new file in /etc/sysctl.d/. This will keep your system package upgradable.
I've prepared a Gist for all the lazy ones: 60-jetbrains.conf (placed this file in /etc/sysctl.d/)
Is there a way to disable the inotify warn in IntelliJ IDEA? In Manjaro Linux and IDEA 2016.1/2016.2 with the default max_user_watches settings everything is OK and I don't see any reason why I should change the setting.
This post suggests two approaches to resolve the issues. The first one is to append a line in /etc/sysctl.conf, however that doesn't work for me! The second approach does work!