Estou executando um kernel Linux 2.6.36 e estou vendo alguns erros aleatórios. Coisas como
ls: error while loading shared libraries: libpthread.so.0: cannot open shared object file: Error 23
Sim, meu sistema não pode executar consistentemente um comando 'ls'. : (
Eu notei vários erros na minha saída do dmesg:
# dmesg | tail
[2808967.543203] EXT4-fs (sda3): re-mounted. Opts: (null)
[2837776.220605] xv[14450] general protection ip:7f20c20c6ac6 sp:7fff3641b368 error:0 in libpng14.so.14.4.0[7f20c20a9000+29000]
[4931344.685302] EXT4-fs (md16): re-mounted. Opts: (null)
[4982666.631444] VFS: file-max limit 1231582 reached
[4982666.764240] VFS: file-max limit 1231582 reached
[4982767.360574] VFS: file-max limit 1231582 reached
[4982901.904628] VFS: file-max limit 1231582 reached
[4982964.930556] VFS: file-max limit 1231582 reached
[4982966.352170] VFS: file-max limit 1231582 reached
[4982966.649195] top[31095]: segfault at 14 ip 00007fd6ace42700 sp 00007fff20746530 error 6 in libproc-3.2.8.so[7fd6ace3b000+e000]
Obviamente, os erros file-max parecem suspeitos, sendo agrupados e recentes.
# cat /proc/sys/fs/file-max
1231582
# cat /proc/sys/fs/file-nr
1231712 0 1231582
Isso também parece um pouco estranho para mim, mas a questão é que não há como ter 1.2 milhões de arquivos abertos neste sistema. Eu sou o único a usá-lo e não é visível para ninguém fora da rede local.
# lsof | wc
16046 148253 1882901
# ps -ef | wc
574 6104 44260
Eu vi alguma documentação dizendo:
file-max & file-nr:
The kernel allocates file handles dynamically, but as yet it doesn't free them again.
The value in file-max denotes the maximum number of file- handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit.
Historically, the three values in file-nr denoted the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles -- this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles.
Attempts to allocate more file descriptors than file-max are reported with printk, look for "VFS: file-max limit reached".
Minha primeira leitura é que o kernel basicamente tem um vazamento de descritor de arquivo embutido, mas eu acho isso muito difícil de acreditar. Isso implicaria que qualquer sistema em uso ativo precisa ser reinicializado de vez em quando para liberar os descritores de arquivo. Como eu disse, não posso acreditar que isso seja verdade, já que é normal para mim ter sistemas Linux permanecendo por meses (até anos) de cada vez. Por outro lado, também não consigo acreditar que meu sistema quase inativo esteja mantendo mais de um milhão de arquivos abertos.
Alguém tem alguma ideia, seja para correções ou diagnóstico adicional? Eu poderia, é claro, apenas reinicializar o sistema, mas não quero que isso seja um problema recorrente a cada poucas semanas. Como uma medida paliativa, eu abandonei o Firefox, que era responsável por quase 2000 linhas de saída lsof (!), Embora eu tivesse apenas uma janela aberta, e agora eu posso rodar 'ls' novamente, mas duvido que isso consertará problema por muito tempo. (editar: Ops, falou cedo demais. Quando terminei de digitar essa pergunta, o sintoma estava de volta)
Agradecemos antecipadamente por qualquer ajuda.
E outra atualização: meu sistema era basicamente inutilizável, então decidi que não tinha outra opção a não ser reiniciar. Mas antes disso, saí cuidadosamente de um processo de cada vez, verificando /proc/sys/fs/file-nr após cada término. Descobri que, previsivelmente, o número de arquivos abertos diminuiu gradualmente quando fechei as coisas. Infelizmente, não foi um grande efeito. Sim, consegui limpar 5000 a 10000 arquivos abertos, mas ainda havia mais de 1,2 milhão. Eu desliguei quase tudo. Todos os shells interativos, exceto pelo ssh que eu deixei aberto para terminar de fechar, httpd, até mesmo serviço nfs. Basicamente tudo na tabela de processos que não era um processo do kernel, e ainda havia um número terrível de arquivos aparentemente deixados em aberto.
Após a reinicialização, descobri que /proc/sys/fs/file-nr mostrou cerca de 2000 arquivos abertos, o que é muito mais razoável. Iniciar duas sessões de Xvnc como de costume, juntamente com as dezenas de janelas de monitoramento que eu gosto de manter abertas, elevaram o total para cerca de 4000 arquivos. Não vejo nada de errado com isso, é claro, mas obviamente não identifiquei a causa raiz.
Ainda estou procurando ideias, pois definitivamente espero que isso aconteça novamente.
E outra atualização, no dia seguinte:
Eu observei o sistema cuidadosamente e descobri que /proc/sys/fs/file-nr apresentou um crescimento de cerca de 900 arquivos abertos por hora. Fechei o único cliente NFS do sistema durante a noite e o crescimento parou. Lembre-se, não liberou os recursos, mas pelo menos deixou de consumir mais. Esse é um bug conhecido com o NFS? Eu vou estar trazendo o cliente NFS de volta online hoje, e vou reduzi-lo ainda mais.
Se alguém estiver familiarizado com esse comportamento, sinta-se à vontade para entrar com "Sim, o NFS4 tem esse problema, volte para o NFS3" ou algo assim.