8

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.

Manohar
  • 3,865
  • 11
  • 41
  • 56
  • 2
    If it were per-process a user could circumvent the limit with a simple `fork()` very easily... – Flexo Jun 19 '12 at 22:17
  • What is so expensive about inotify instances that it has to be limited per user id ? Note that we are talking about just inotify FDs not the inotify watches being added. – Manohar Jun 19 '12 at 22:20

1 Answers1

14

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 and max_user_watches), although in the end max_user_instances was removed and max_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.

jleahy
  • 16,149
  • 6
  • 47
  • 66