Bugzilla – Bug 1222946
raise default inotify instance limit
Last modified: 2024-04-26 15:19:35 UTC
especially when running Unison, I quite often experienced the following error: `Fatal error: exception Unix.Unix_error(Unix.EBADF, "set_nonblock", "")` Running "strace unison-fsmonitor" yielded: ``` fcntl(0, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) fcntl(0, F_SETFL, O_RDWR|O_NONBLOCK) = 0 fcntl(1, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK) = 0 inotify_init() = -1 EMFILE (Too many open files) fcntl(-1, F_GETFL) = -1 EBADF (Bad file descriptor) write(2, "Fatal error: exception Unix.Unix"..., 71Fatal error: exception Unix.Unix_error(Unix.EBADF, "set_nonblock", "")) = 71 exit_group(2) = ? +++ exited with 2 +++ ``` Sometimes closing open IDEs or Firefox has helped, but the culprit seems to be the standard value of fs.inotify.max_user_instances = 128 After doubling the number, I was able to use Unison, again. Others have observed this issue, too: https://intellij-support.jetbrains.com/hc/en-us/articles/15268110231826-Inotify-Instances-Limit-Linux ---quote For an intelligent IDE, it is essential to be in the know about any external changes in files it working with - e.g. changes made by VCS, or build tools, or code generators, etc. For that reason, the IntelliJ platform spins a background process to monitor such changes. The method it uses is platform-specific, and on Linux, it is the Inotify facility. Before operating, inotify requires an "instance" to be initialized. While the default per-user limit of instances used to be high enough, a growing number of programs that also use inotify may lead to instance shortage - in which case file watcher will be unable to start. If this is the case, the limit may be temporarily increased by the following command: sudo sh -c "echo 256 > /proc/sys/fs/inotify/max_user_instances" Don't forget to restart the IDE afterward. ---quote My workaround at present is: `sysctl -w fs.inotify.max_user_instances=256 >> /etc/sysctl.d/unison.conf` This is also documented at https://github.com/bcpierce00/unison/issues/1019
Created attachment 874359 [details] output of inotify-consumers script 94 out of 128 instances seems pretty close to the default limit and I do not see any process consuming a really excessive amount - except for dolphin, maybe. This is OpenSuSE Leap 15.5 Script obtained from https://github.com/fatso83/dotfiles/blob/master/utils/scripts/inotify-consumers Cf. https://stackoverflow.com/questions/13758877/how-do-i-find-out-what-inotify-watches-have-been-registered
The default value is hardcoded to 128 even in the latest upstream code, and I see no big gain to have an extra kernel config for defining it when an easy tuning knob with sysctl is already present. I bet the suggestion to the upstream would be declined by that reason, too. You can statically set the value in /etc/sysctl.d/* instead. e.g. unison package may contain such a sysctl snippet.
Created attachment 874522 [details] output of inotify-consumers script with active unison Same script as mentioned in comment 1, this now with unison load active. Situation in is a system workload on a normal working day. 171 inotify instances active - and no single massive consumer in sight. Okular and akonadi could be somewhat in focus. Seems to me as if Unison erroring out has been the symptom, but not the cause. BTW, the Unison developers claim that as they only use 1 instance at most, it is not their responsibility to deal with a lack of resources on the OS. The problem with Unison was a misleading error message, which they fixed. Bug is linked. In this light, and given the number above I wonder how many of the listed instance consumers do not produce error messages at all, if instances are exhausted? The only program producing an error has been Unison. I am sure with current settings I will hit ~200 instances with IDEs open. I do not even have Eclipse or Intellij open during the above snapshot. If not for general use, at least with a desktop (KDE?) profile it may make sense to raise the limit, if you have a mechanism for that.