Aquando da atualização de uma máquina com o debian buster deparámo-nos com o seguinte erro:
...
dpkg: erro fatal irrecuperável, a abortar:
não foi possível criar `/var/lib/dpkg/updates/tmp.i': Não há espaço disponível no dispositivo"
...
Não existiria espaço de armazenamento nessa unidade. Vejamos o que se passa, como root executar:
df -h
e o resultado:
Sist.fichs Tama Ocup Livre Uso% Montado em
...
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/mapper/vg_system-lv_var 4,6G 2,9G 1,5G 66% /var
/dev/sda2 939M 88M 804M 10% /boot
...
Afinal ainda está disponível um espaço de armazenamento de 1,5G!
A próxima questão que se nos coloca é se esta falta de espaço pode significar o esgotar dos inodes nesse sistema de ficheiros.
Em um sistema de arquivos de estilo Unix, um nó de índice[1], informalmente referido como um nó-i (inode), é uma estrutura de dados que descreve um objeto do sistema de arquivos, que pode ser uma de várias coisas, incluindo um arquivo ou diretório. Cada inode armazena os atributos e a(s) localização(ões) de bloco de disco dos dados dos objetos. Atributos de objeto do sistema de arquivos podem incluir metadados (horários de última alteração, acesso e modificação), bem como dados de proprietário e permissão (por exemplo, id de grupo, id de usuário, permissões).
Diretórios são listas de nomes atribuídos a inodes. Um diretório contem uma entrada para ele mesmo, seus pais e cada um de seus filhos.
https://pt.wikipedia.org/wiki/N%C3%B3-i
Vamos então verificar a disponibilidade de inodes no sistema de ficheiros:
df -i /var
e o resultado:
Sist.fichs Inodes IOcup ILivr UsoI% Montado em
/dev/mapper/vg_system-lv_var 305216 305216 0 100% /var
Efetivamente está esgotado o número de inodes disponíveis.
De acordo com o que se pode ler aqui https://access.redhat.com/solutions/641333 não é possível expandir o número de inodes depois da criação do sistema de ficheiros.
Na verdade, salvo rara excepção, para que ocorra um esgotamento do número de inodes disponível num sistema de ficheiros é porque provavelmente foi criado um número anormal de ficheiros.
A próxima tarefa será a de compreender qual a pasta ou pastas que estão a consumir a grande maioria dos inodes e estão a contribuir de forma mais significativa para o seu esgotamento e depois avaliar a possibilidade da eliminação desses ficheiros. Para isso executamos:
find /var -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n
...
646 /var/lib/docker/overlay2/9716f0bcea65f951a32fbe323043960a53c77c3f3e18e831e1b1706a27cb8381/diff/usr/lib/python2.7
1204 /var/lib/app-info/icons/debian-buster-main/128x128
1364 /var/lib/app-info/icons/debian-buster-main/48x48
1852 /var/lib/app-info/icons/debian-buster-main/64x64
10512 /var/lib/dpkg/info
93895 /var/spool/exim4/msglog
187790 /var/spool/exim4/input
As duas últimas entradas da lista aclaram o possível causador deste problema, o nosso MTA (agente de transporte de e-mail), o exim4.
Os e-mails em causa são na quase totalidade criados por outro software e de menor importância. Como apagar diretamente os ficheiros nessas pastas poderia acarretar um conjunto de problemas indesejados fá-lo-emos utilizando as ferramentas proporcionadas pelo exim:
exim -bp | exiqgrep -i | xargs exim -Mrm
Falta verificar se o problema ficou resolvido:
df -i /var
e o resultado:
Sist.fichs Inodes IOcup ILivr UsoI% Montado em
/dev/mapper/vg_system-lv_var 305216 24402 280814 8% /var
https://www.maketecheasier.com/fix-linux-no-space-left-on-device-error/
https://unix.stackexchange.com/questions/117093/find-where-inodes-are-b…
https://www.cyberciti.biz/faq/exim-remove-all-messages-from-the-mail-qu…