tail: inotify não pode ser usado, revertendo para polling: muitos arquivos abertos

9

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

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

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

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

Quando eu 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 é aberto 17,13,10,10,9? Ou estou entendendo errado? E todos esses eram bash, sshd, apache2, tomcat tinha o número 4.

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

    
por gbag 24.05.2013 / 23:56

6 respostas

10

Isso foi resolvido para mim seguindo as instruções do link

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

fs.inotify.max_user_watches=1048576

para:

/etc/sysctl.conf

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

faça um

sysctl -p
    
por Elan Hasson 06.10.2016 / 22:56
9

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

Existem dois limites relativos 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 ; }' | 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
por Radu Rădeanu 20.09.2013 / 14:10
6

Provavelmente, você ficou sem seus inotify reló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 comando tail -f usa o mecanismo inotify por padrão, para monitorar as alterações do arquivo. Se você ficar sem todos os inotify watches (8192 por padrão), então inotify -f precisará alternar para pesquisa para detectar alterações nesse arquivo.

É claro que você pode modificar o número máximo de inotify relógios.

reference:
link
link
link

    
por zeekvfu 04.12.2013 / 16:42
3

sysctl fs.inotify.max_user_instances teria limite por usuário para inotify .

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

    
por JBat 12.03.2016 / 18:08
2

Executar

ps aux | grep tail

para verificar se há muitos comandos tail em execução, como um spawn por crontab.

    
por tangxinfa 13.12.2016 / 07:31
0

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

link

    
por thom 24.11.2013 / 04:43