Respostas:
Depois de fazer algumas pesquisas, encontrei a solução. Execute o comando abaixo.
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pPara o Arch Linux, adicione esta linha ao /etc/sysctl.d/99-sysctl.conf:
fs.inotify.max_user_watches=524288fs.inotify.max_user_watches=524288a /etc/sysctl.d/99-sysctl.confe, em seguida, executar sysctl --system. Isso também persistirá nas reinicializações. Para obter mais detalhes: wiki.archlinux.org/index.php/Sysctl
npm dedupeesclareceu para mim. problema
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf grava no final do arquivo /etc/sysctl.conf a linha "fs.inotify.max_user_watches = 524288" sudo sysctl -p reconfigura o kernel no tempo de execução, carregando o arquivo /etc/sysctl.conf como um parâmetro
A qualquer momento que você precisar executar sudo something ...para corrigir algo, faça uma pausa para pensar no que está acontecendo. Embora a resposta aceita aqui seja perfeitamente válida, ela está tratando o sintoma e não o problema. É o equivalente a comprar alforjes maiores para resolver o problema de: error, não é possível carregar mais lixo no pônei. O pônei já carrega tanto lixo que está desmaiando de exaustão.
Uma alternativa (talvez comparável a retirar o excesso de lixo do pônei e colocar no lixão) é executar:
npm dedupeEntão vá se felicitar por fazer o pônei feliz.
sudoe agora está funcionando para mim.
fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -pcomo na resposta aceita, mas +1 para Ensina-menpm dedupe
Depois de tentar a resposta da granada, você pode usar uma correção temporária:
sudo bash -c 'echo 524288 > /proc/sys/fs/inotify/max_user_watches'Isso faz o mesmo que a resposta do kds , mas sem persistir nas alterações. Isso é útil se o erro ocorrer apenas após algum tempo de atividade do seu sistema.
Para descobrir quem está fazendo instâncias inotify , tente este comando ( fonte ):
for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nrO meu ficou assim:
25 /proc/2857/fd/anon_inode:inotify
9 /proc/2880/fd/anon_inode:inotify
4 /proc/1375/fd/anon_inode:inotify
3 /proc/1851/fd/anon_inode:inotify
2 /proc/2611/fd/anon_inode:inotify
2 /proc/2414/fd/anon_inode:inotify
1 /proc/2992/fd/anon_inode:inotifyUsando ps -p 2857, consegui identificar o processo 2857 como sublime_text. Somente depois de fechar todas as janelas sublimes, consegui executar o script do nó.
Eu encontrei esse erro depois que meu PC cliente travou, o jest --watchcomando que eu estava executando no servidor persistiu e tentei executar jest --watchnovamente.
O aditamento ao /etc/sysctl.confdescrito nas respostas acima trabalharam contornar esse problema, mas também era importante encontrar meu velho processo via ps aux | grep nodee kill-lo.
No meu caso, estava relacionado ao código vs em execução na minha máquina Linux. Eu ignorei um aviso que apareceu sobre o observador de arquivos bla bla. A solução está na página de documentos vs-code do linux https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in- this-large-workspace-error-enospc
A solução é quase a mesma (se não a mesma) das respostas aceitas, apenas tem mais explicações para quem chega aqui depois de encontrar os problemas do código vs.
No meu caso, descobri que tenho um plugin agressivo para o Vim, apenas o reiniciei.
gruntmas sim de qualquer programa usando o inotify abaixo. Há uma boa explicação em unix.stackexchange.com/questions/13751/… .