GNOME Bugzilla – Bug 753549
g_file_monitor should signal error when maximum number of watches has been reached
Last modified: 2018-05-24 18:02:52 UTC
Emacs now has the possibility to place watches on files and directories to get notified when they change. It can do that on GNU/Linux systems either with plain inotify or via glib's GFileMonitor (which uses inotify under the hoods, too, at least on my system). In the latter case, there is the problem that g_file_monitor doesn't signal an error when the limit of watches a user may place is reached. Here's a receipe: 1. As root, execute "sysctl fs.inotify.max_user_watches=0" to set the maximum number of watches a user is allowed to set to 0. 2. Validate that this setting works: $ inotifywait . Setting up watches. Failed to watch .; upper limit on inotify watches reached! Please increase the amount of inotify watches allowed per user via `/proc/sys/fs/inotify/max_user_watches'. 3. Now the following glib api call GError *err = NULL; monitor = g_file_monitor (gfile, gflags, NULL, &err); still returns a GFileMonitor and err won't be set. According to the docs, it should return NULL and set err in case of any error. And IMHO, reaching the limit is an error. There is no way to figure out that the GFileMonitor won't work. It just looks like the watched file or directory never changes although it does. I've had a brief look at the glib code and it seems that the error is at least considered in the low-level gio/inotify/*.c code but somehow is lost somewhere. This is the bug about the issue I've filed for Emacs: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21241
I agree.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1070.