O espaço esgotado é a razão mais frequente para um servidor deixar de funcionar sem qualquer má intenção pelo meio. O sítio devolve 500, a base de dados não escreve, o correio não sai, e o df -h entretanto indica vários gigabytes livres. Vejamos os três casos em que isso acontece e, já agora, o que convém saber sobre o SMART.

Caso um: acabaram os inodes

Um sistema de ficheiros guarda dois recursos limitados: o espaço para o conteúdo e os registos sobre os ficheiros. O segundo esgota-se independentemente do primeiro:

df -h
df -i

Se o IUse% no segundo comando for 100, a questão são os inodes. Há espaço, mas não se consegue criar um único ficheiro, nem sequer vazio.

Os culpados são sempre os mesmos: milhões de ficheiros minúsculos. As sessões PHP em /var/lib/php/sessions com a recolha partida. Uma cache de aplicação que nunca é limpa. Uma fila de correio encravada. Uma pasta de miniaturas. Encontram-se assim:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

O comando lista as pastas com mais ficheiros. Num sistema grande demora minutos: é normal.

Caso dois: o ficheiro está apagado e o espaço não voltou

Situação mais traiçoeira. Alguém apagou com rm um registo desmesurado, mas o processo que lá escrevia continua a mantê-lo aberto. O ficheiro já não está na pasta, o espaço continua ocupado, e assim ficará até o processo ser reiniciado.

sudo lsof +L1

O comando mostra os ficheiros sem referência no sistema de ficheiros mas ainda retidos por um processo. A cura é reiniciar ou recarregar com suavidade esse processo, não procurar «para onde foram os gigabytes».

Daí a regra: um registo desmesurado não se apaga, esvazia-se, e assim o descritor aberto continua utilizável:

sudo truncate -s 0 /var/log/huge.log

E logo a seguir configura-se a rotação, caso contrário tudo se repetirá dentro de uma semana.

Caso três: foram os registos

Para onde foi exatamente o espaço vê-se descendo nível a nível:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

A opção -x impede de sair para outros sistemas de ficheiros; sem ela a contagem entra em /proc e nas montagens de rede. Tudo isto é mais cómodo no ncdu, se estiver disponível.

Os devoradores habituais:

  • journald. Um comando resolve: journalctl --disk-usage. Limita-se com a linha SystemMaxUse=500M em /etc/systemd/journald.conf e limpa-se uma vez com journalctl --vacuum-size=200M;
  • os registos das ferramentas de segurança. O Suricata com a configuração padrão escreve trinta tipos de eventos e não configura rotação nenhuma: num servidor real isso deu 15 GB em dois dias. O mesmo acontece com o audit.log e com os registos de depuração do nginx;
  • as cópias de segurança guardadas no mesmo disco e nunca removidas;
  • a cache do apt: o apt clean devolve por vezes um par de gigabytes.

Uma palavra sobre /boot

Uma partição pequena que se enche de núcleos antigos. Por si só não deita o sítio abaixo, em compensação trava por completo as atualizações: o núcleo novo não instala e atrás dele fica presa toda a fila de pacotes. Resolve-se com apt autoremove --purge e previne-se ativando a remoção automática de núcleos não usados nas definições das atualizações automáticas.

SMART: que atributos importam

Primeiro uma ressalva: num servidor virtual o SMART costuma não estar disponível, porque o disco é virtual e o físico por baixo não se vê. Não é avaria, simplesmente não há dados. Tudo o que se segue diz respeito a servidores dedicados e a hardware próprio.

sudo smartctl -a /dev/sda

A linha SMART overall-health self-assessment test result: PASSED não é motivo para descansar: mantém-se verde praticamente até à avaria. O que há que ver são os contadores concretos:

  • 5, Reallocated_Sector_Ct: setores realocados. Diferente de zero significa que o disco já está a degradar-se; se aumentar, substitua-o sem adiar;
  • 197, Current_Pending_Sector: setores ilegíveis à espera de decisão. O mais alarmante de todos: costuma significar que parte dos dados já não é recuperável;
  • 198, Offline_Uncorrectable: o mesmo, confirmado por uma verificação;
  • SSD: Percentage Used / Media_Wearout_Indicator: a resistência de escrita consumida. Uma grandeza previsível, sobre a qual se planeia a substituição.

A temperatura e as horas de funcionamento, pelo contrário, nada dizem por si: um disco com cinco anos de serviço e contadores de erro a zero é mais fiável do que um novo com um 1 no atributo 197.

O sentido da vigilância

Tudo o que ficou dito é reação ao que já aconteceu. Ora, tanto o enchimento de um disco como o desgaste de um SSD são processos lentos e perfeitamente previsíveis: uma curva de ocupação de duas semanas aponta a data em que o espaço acabará muito antes de isso suceder. A diferença entre «o sítio está em baixo desde as três da manhã» e «na quinta-feira é preciso limpar os registos» está apenas em ter o número à vista. Como fica tudo reunido mostra-o a página de demonstração abaixo.