This specifies an upper limit on the number of watches that can be created per real user ID
Listen uses inotify by default on Linux to monitor directories for changes. It's not uncommon to encounter a system limit on the number of files you can monitor. For example, Ubuntu Lucid's (64bit) inotify limit is set to 8192.
guard says like:
Unable to monitor filesystem Please run: echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches and restart Dropbox to correct the problem.
No space left on device - Failed to watch "…": The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource. (Errno::ENOSPC)
Is it safe to raise that value and what would be the consequences of a too high value?
Yes, it's safe to raise that value and below are the possible costs [source]:
- Each used inotify watch takes up 540 bytes (32-bit system), or 1 kB (double - on 64-bit) [sources: 1, 2]
- This comes out of kernel memory , which is unswappable.
- Assuming you set the max at 524288 and all were used (improbable), you'd be using approximately 256MB/512MB of 32-bit/64-bit kernel memory.
- Note that your application will also use additional memory to keep track of the inotify handles, file/directory paths, etc. -- how much depends on its design
To see current value do
But we probably want it highish. I see recommends at ex:
From my limited research I might be comfortable with either 1/2 (262114) or 1/4 (131072) as well.
Based on some bug reports - 128k seems to be ceiling .. or floor.. for some. Though I guess it all depends on amount of stored data. If the above is to believed though, maybe setting a maximum of 128/256mb for kernel to monitor files is enough until proven otherwise.
(and yes though - whatever decided, this shouldnt be a DE-specific consideration.)