web-dev-qa-db-fra.com

tail: inotify ne peut pas être utilisé, revenant à polling: Trop de fichiers ouverts

Lorsque j'essaie de tail -f catalina.out, j'obtiens l'erreur suivante:

tail: inotify cannot be used, reverting to polling: Too many open files

J'ai essayé la réponse dans ce post: Trop de fichiers ouverts - comment trouver le coupable

lsof | awk '{ print $2; }' | sort -rn | uniq -c | sort -rn | head

Quand j'ai exécuté la commande ci-dessus, la sortie était

17 6115

13 6413

10 6417

10 6415

9 6418

9 6416

9 6414

8 6419

4 9 

4 8

Je ne vois aucun processus ayant 1024 fichiers ouverts. Le nombre de fichiers ouverts n'est-il pas 17,13,10,10,9? Ou est-ce que je comprends mal? Et tout cela était bash, sshd, Apache2, Tomcat avait le numéro 4.

J'ai aussi fait lsof | grep tail | wc -l qui a retourné 20. Ces chiffres ne sont pas énormes, alors pourquoi tail -f catalina.out échoue?

bashapache2tomcatsshdtail
14
gbag

Cela a été résolu pour moi en suivant les instructions sur http://peter-butkovic.blogspot.com/2013/08/tail-inotify-resources-exhausted.html

Solution permanente (préservée lors des redémarrages) Ajout d'une ligne:

fs.inotify.max_user_watches=1048576

à:

/etc/sysctl.conf

fixe la valeur limite en permanence (même entre les redémarrages).

puis faire un

sysctl -p
14
Elan Hasson

Je pense que cette réponse n'est pas complet (il ne dit rien sur la limite maximale de fichiers ouverts sur le système).

Il existe deux limites concernant le nombre maximal de fichiers ouverts:

  1. Limite maximale de fichiers ouverts par processus .

    • Vous pouvez voir quelle est la valeur de cette limite en utilisant: ulimit -n
    • Vous pouvez changer cette limite en utilisant: ulimit -n new_limit_number

    • Voici une commande pour obtenir le top 10 des processus ayant de nombreux fichiers ouverts:

      lsof | awk '{ print $2; }' | sort -rn | uniq -c | sort -rn | head

  2. Nombre maximal de fichiers ouverts par système .

    • Vous pouvez voir quelle est la valeur de cette limite en utilisant: cat /proc/sys/fs/file-max
    • Vous pouvez changer cette limite en utilisant: echo new_limit_number > /proc/sys/fs/file-max
    • Compter tous les descripteurs de fichiers ouverts: lsof | wc -l
9
Radu Rădeanu

Très probablement, vos montres inotify sont épuisées. Vous exécutez probablement des outils de synchronisation de fichiers (p. Ex. Dropbox) en arrière-plan?

Sous Linux, l’implémentation interne de la commande tail -f utilise par défaut le mécanisme inotify afin de surveiller les modifications de fichier. Si toutes les analyses inotify (8192 par défaut) sont épuisées, inotify -f doit alors passer en interrogation pour détecter les modifications apportées à ce fichier.

Bien entendu, vous pouvez modifier le nombre maximal de surveillances inotify.

référence:
http://www.quora.com/How-is-tail-f-implemented
http://peter-butkovic.blogspot.com/2013/08/tail-inotify-resources-exhausted.html
https://serverfault.com/questions/510708/tail-inotify-cannot-be-utiliser-reverting-to-polling-too-many-open-files

6
zeekvfu

sysctl fs.inotify.max_user_instances aurait une limite par utilisateur pour inotify.

Je l’ai expérimenté, et toutes les limites du système étaient suffisamment élevées, mais les réglages par utilisateur sont généralement relativement faibles par défaut. Vous pouvez l’augmenter en sysctl.conf et le recharger avec sysctl -p.

3
JBat

Courir

ps aux | grep tail

pour vérifier si trop de commandes de queue sont en cours d'exécution, comme un spawn par crontab.

3
tangxinfa

Vérifiez la version de votre noyau, il pourrait s'agir de ce bogue:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101666

0
thom