Cet article de janvier 2022 apporte des réponses sur la limite et la récursivité : https://www.baeldung.com/linux/inotify-upper-limit-reached
inotifywatch --recursive « Here, the system allows 524288 (2^19) watches. » « Because each watch is a structure, available memory is also a bottleneck for using inotify. In fact, a watch can take up to 1KB of space. This means a million watches could result in 1GB of extra RAM usage. » 5.2. inotify Watch Limit Consider that a recursive inotifywatch on / would take up as many watches as there are files. Indeed, doing that on a filesystem with more files than the watch limit would produce an error: etc. Avez-vous une expérience avec la récursivité et les limites que cela peut engendrer avec les limites ? Début du message transféré : > De: NoSpam <no-s...@tootai.net> > Date: 12 janvier 2023 à 16:01:21 UTC+1 > À: debian-user-french@lists.debian.org > Objet: Rép. : Détecter un changement dans un répertoire > Répondre à: no-spam@tootai.invalid > > > Bonjour > > Le 12/01/2023 à 15:57, roger.tar...@free.fr a écrit : >> Bonjour, >> et encore bonne année à tous, >> >> Je cherche à surveiller ce qui se passe dans un répertoire. >> >> Il semble exister plusieurs solutions. >> La plus basique consiste à examiner les fichiers déposés, par exemple toutes >> les minutes (via cron ou avec un programme qui tourne en boucle et se met en >> pause 1 mn après chaque boucle). >> Je suis plus intéressé par une programmation événementielle où le programme >> réagit si de nouveaux fichiers sont déposés ou modifiés et détectés par le >> système. >> Pour faire ça, j'avais examiné inotify mais constaté qu'il y aurait des >> limitations (de mémoire, par exemple, sur le nombre de fichiers traitables, >> de inode, etc.). >> >> J'ai repéré notamment : auditd, fswatch, inotify/inotifywait. >> >> Selon vous, pour traiter ce besoin quelle est la solution _FIABLE_ ? (cad >> qui ne provoque pas d'effets de bord... ou de surprise) >> >> Par ailleurs, pour traiter le cas où des fichiers dépendants les uns des >> autres sont déposés en vrac, il serait intéressant de pouvoir disposer d'un >> historique détaillé par fichier, exploitable. >> Je suppose que ça doit être prévu (inotify le fait). > incron fait cela à la perfection
