In Linux, limit on the number of inotify instances a process can have open is limited by a per user-id max number, specified in /proc/sys/fs/inotify/max_user_instances
Natural thing would be to limit it per process, like file FDs for example. Since the inotify FDs are limited by the user id, its more likely to hit the limit on servers where many processes might run with the same user id. But I guess there has to be a reason for this ?
This is a programming question because I have to use inotify in my code and want to set the right limit for the system.
The reason is to prevent non-root users DoSing the system by watching lots of files using
inotify
.inotify
structures require non-negligible amount of memory to maintain (and it can't be swapped out to disk), so there needs to be some limit on how much non-privileged can commit.epoll
used to have similar restrictions (max_user_instances
andmax_user_watches
), although in the endmax_user_instances
was removed andmax_user_watches
was just set to be 4% of memory.A similar patch should probably be submitted for inotify, but hasn't been so far.
File descriptors are limited on a per-process basis for a completely different reason: when a process starts a file descriptor table is allocated and its size is proportional to the maximum allowed number of file descriptors. Keeping this as small as possible reduces the per-process memory overhead.