Solução para: No space left on device

Quando administramos servidores Linux nem sempre as coisas executam como deveriam, e nestes casos temos que encotrar soluções rápidas e eficazes para o problema.

Um bom exemplo disso é algo que parece um pouco bizarro. De repente nada mais funciona, os sites param, o banco de dados sai do ar e qualquer tentativa de criar um novo arquivo é bloqueada. E mesmo se tentarmos instalar uma nova app recebemos a mensagem “No space left on device”.

Isso ocorre porque o HD ficou sem espaço livre, e o mais bizarro como neste caso que irei demonstrar é que ele vai a 100% de uso em apenas algumas horas.

A causa mais comum disso ocorrer é a de que o Garbage Collector do PHP parou de funcionar. Isso faz com que as SESSIONS (arquivos de sessões) do site parem de reciclar. Pelo que diz o manual do PHP elas deveriam ser deletadas a cada 24 minutos, mas isso não ocorre porque algo parou de funcionar como deveria.

Em sites com muitos acessos são criadas centenas de novas sessions por minuto. Mas ai você pode pensar que está tudo bem mesmo assim pois cada sessions tem o tamanho menor do que 1k e nunca irá ocupar todo o HD. O HD irá lotar rapidamente sim, veja porque:

Além do espaço do HD existe um outro espaço que é pouco conhecido chamado Index Nodes ou “inodes”, é como se fosse uma tabela de referência para cada arquivo criado no HD. Ous seja, a cada novo arquivo é criado uma entrada nessa tabela inode, e este número é limitado. Você pode ver o consumo desse espaço com o comando:

> df -i

O comando acima irá mostrar o percentual de ocupação em “rootfs” (Debian 7). Note que se você está com este problema ela aparecerá com 100% de ocupação quando o normal seria em torno de 10% ou perto disso.

Mas e porque o HD lota?

Isso é simplesmente porque não há mais como criar novos arquivos e todos os serviços começam a disparar mensagens de logs. E a coisa fica ainda pior.. Como não há como criar novos arquivos os arquivos de log também não conseguem fazer o rotation e continuem adicionando milhões de novas linhas de mensagens de erro a cada minuto. Com isso o espaço livre em disco pode ir de 40% a 100% em apenas 2 horas, dependendo do caso.

Muito bem agora já sabemos que, pelo que foi dito acima, existem uma quantidade enorme de arquivos entulhados em algum do sistema (normalmente são milhões de arquivos pequenos num único lugar). E então a gente retorna ao diretório onde o PHP guarda as sessions, que em sites com ISPConfig está em /tmp do espaço de site (este diretório fica no mesmo nivel de /web do site). Se você tentar exibir este diretório irá demorar minutos para mostrar o conteúdo.

Para encontrar o site ou diretório vilão, onde estão os arquivos todos, digite o seguinte comando:

> cd /var/www

> for i in *; do echo $i; find $i |wc -l; done

Aparecerá uma lista de pastas e o total de arquivos. Continue carregando os diretórios maiores e repetindo o comando acima até encontrar em qual site está o problema. Uma vez que consiga encontrar o diretório, por exemplo: /var/www/fatorbinario.com/tmp então acesse ele e digite o comando:

> rm sess_*

Mas caso não consiga executá-lo é porque a lista de arquivos é tão grande que não permite nem fazer isso. Então a solução é a seguinte:

> rm sess_a*

> rm sess_b*

> rm sess_c*

E assim por diante, ou seja, continue trocando as letras antes do asterisco até o final do alfabeto. Note que depois de deletar todos os arquivos de sessions a partição onde fica os inodes irá liberar espaço permitindo novas ações.

Depois de deletar os arquivos é necessário reiniciar o servidor para que tudo volte a normalidade pois muitos serviços pararam de funcionar por causa do problema.

*Depois de reiniciar o servidor ainda será necessário criar um script que faça a limpeza da pasta com problema e agendá-lo no CRON para que apague sessions mais antigas que 24 minutos.