tail: inotify não pode ser usado, revertendo para sondagem: Muitos arquivos abertos

Quando tento tail -f catalina.out, recebo o erro:

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

Tentei a resposta neste post: Muitos arquivos abertos - como encontrar o culpado

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

Quando executei o comando acima, a saída foi

17 6115

13 6413

10 6417

10 6415

9 6418

9 6416

9 6414

8 6419

4 9 

4 8

Não vejo nenhum processo com 1024 arquivos abertos. O número de arquivos não está aberto 17,13,10,10,9? Ou estou entendendo errado? E todos estes eram bash, sshd, apache2, tomcat tinha o número 4.

Eu também fiz o lsof | grep tail | wc -l que voltou 20. Esses números não são enormes, então por que tail -f catalina.outfalha?

Isso foi resolvido para mim seguindo as instruções em http://peter-butkovic.blogspot.com/2013/08/tail-inotify-resources-exhausted.html

Solução permanente (preservada nas reinicializações) Adicionando linha:

fs.inotify.max_user_watches=1048576

para:

/etc/sysctl.conf

fixou o valor limite permanentemente (mesmo entre as reinicializações).

então faça um

sysctl -p

Acho que a resposta não está completa (não diz nada sobre o limite máximo de arquivos abertos no sistema).

Existem dois limites em relação ao número máximo de arquivos abertos:

1. Limite máximo de arquivos abertos por processo .

   • Você pode ver qual é o valor desse limite usando: ulimit -n
   • Você pode alterar esse limite usando: ulimit -n new_limit_number

   • Aqui está um comando para obter os 10 principais processos com muitos arquivos abertos:

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

2. Limite máximo de arquivos abertos por sistema .

   • Você pode ver qual é o valor desse limite usando: cat /proc/sys/fs/file-max
   • Você pode alterar esse limite usando: echo new_limit_number > /proc/sys/fs/file-max
   • Contar todos os identificadores de arquivos abertos: lsof | wc -l

Provavelmente, você ficou sem seus inotifyrelógios. Provavelmente, você está executando algumas ferramentas de sincronização de arquivos (por exemplo, Dropbox) em segundo plano?

No Linux, a implementação interna do tail -fcomando usa o inotifymecanismo por padrão, para monitorar as alterações no arquivo. Se você ficar sem todos os inotifyrelógios (8192 por padrão), inotify -fprecisará mudar para a pesquisa para detectar alterações nesse arquivo.

Obviamente, você pode modificar o número máximo de inotifyrelógios.

referência:
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-used-reverting-to-polling-too-many-open-files

sysctl fs.inotify.max_user_instancesobteria limite por usuário para inotify.

Eu experimentei e todo o sistema de limites era alto o suficiente, mas a configuração por usuário geralmente é relativamente baixa por padrão, você pode aumentá-lo sysctl.confe recarregá-lo com o mesmo valor sysctl -p.

Corre

ps aux | grep tail

para verificar se há muitos comandos de cauda em execução, como uma desova por crontab.

Verifique sua versão do kernel, pode ser este bug:

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