Espaço em disco do Linux cheio

Use algo como ncdu para visualizar o uso do espaço em disco. Existem outras ferramentas semelhantes também, mas esta funciona sem UI e funciona muito bem!

https://dev.yorhel.nl/ncdu

Teria sido útil se você tivesse fornecido os comandos reais que forneceram esses resultados (parece ser df & du).

Parece que há 18G usado em /.

Isso é ruim.

Você NUNCA deve adicionar arquivos lá. Isso não apenas cria problemas com o gerenciamento do armazenamento, mas também implica que você está executando tarefas de processamento de dados ou registrando uma raiz. Também é ruim.

Como posso ver o que realmente está ocupando esse espaço?

ls -lst /seria um bom ponto de partida.

Você não verá os arquivos que foram excluídos (mas ainda estão abertos). lsof | grep 'deleted'pode ajudar se você não vê o que esperals

Etapa 1, veja o que você pode encontrar no sistema de arquivos ativo:

du -xm / | sort -n | tail -40

• Execute duno sistema de arquivos com problema ( /),
• Use -x para limitar o exame a esse sistema de arquivos
• Use -m para simplificar a classificação (acho um pouco mais legível do que usar -hem ambos)

Se encontrar algo grande, você poderá examiná-lo e removê-lo. Se não encontrar os 28G de dados correspondentes, provavelmente uma das duas coisas está acontecendo:

• Abra arquivos excluídos. Enquanto um arquivo de log ou outro estiver aberto, a exclusão o removerá do diretório (não mais visível para du), mas não do sistema de arquivos. Você pode verificar aqueles com sudo lsof -nP +L1. (consulte https://unix.stackexchange.com/questions/68523/find-and-remove-large-files-that-are-open-but-have-been-deleted ). Se esta for uma máquina de usuário único e não for muito onerosa, considere apenas reinicializar para desconectar todos os identificadores de arquivos abertos e permitir que o sistema de arquivos libere espaço.

• Ocultação do ponto de montagem. Se houver dados (por exemplo) nos diretórios varou tmp, esses dados ficarão ocultos do acesso quando os /varsistemas /tmpde arquivos e forem montados no topo. Você pode desmontá-los e examiná-los um por um ou dar uma olhada em https://unix.stackexchange.com/questions/4426/access-to-original-contents-of-mount-point . Usando essa técnica, você pode remontar uma cópia do /, executar du nessa cópia e examinar abaixo dos pontos de montagem.

Sempre que isso acontece comigo, faço uma recursão manual, algo como:

du -hs /* > /du.out

Então, quando for aparente que o inchaço vem de (digamos:) /var, repito o processo:

du -hs /var/* > /var/du.out

Enxágue e repita até chegar ao local do problema.

Obviamente, o que foi dito acima poderia ser melhorado como algum tipo de script; mas de modo geral, se a unidade estiver cheia; então você terá apenas o pequeno espaço reservado para o root e muitos programas não serão executados se precisarem de espaço disponível no disco.

Às vezes, alguns arquivos foram excluídos, mas o processo ainda abre o arquivo, execute este comando talvez descubra o processo

lsof | grep deleted

E então mate-o

kill -9 $pid

Estas são as etapas de verificação detalhadas

## check disk size
$ du -sh /data 2>/dev/null
956M    /data

$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb         50G 1008M   46G   3% /data

## create a 2GB file
$ dd if=/dev/zero of=/data/myfile.iso bs=1024k count=2000
2000+0 records in
2000+0 records out
2097152000 bytes (2.1 GB) copied, 1.49613 s, 1.4 GB/s

## check disk size again
$ du -sh /data 2>/dev/null
2.9G    /data

$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb         50G  3.0G   44G   7% /data

## create and run demo script
$ cat test.py 
import time
f = open('/data/myfile.iso','r')
time.sleep(1200)

$ nohup python test.py &
[1] 1522
nohup: ignoring input and appending output to ‘nohup.out’

## Delete file, and then check disk size
$ rm -f myfile.iso

## now disk size is different, "du" print "956M" and "df" print "3.0G"
$ du -sh /data 2>/dev/null
956M    /data

$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb         50G  3.0G   44G   7% /data

## find the deleted file and kill process pid
$ lsof |grep delete
python     1522          root    3r      REG               8,16 2097152000         12 /data/myfile.iso (deleted)

$ kill 1522
[1]+  Terminated              nohup python test.py

## This is end of disk size, du and df is eq
$ du -sh /data 2>/dev/null
956M    /data

$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb         50G 1008M   46G   3% /data

Acho que a questão mais óbvia de por que só podemos ver 18 GB usados ​​em du28 GB usados df​​está na duimagem.

Se você olhar atentamente para cima, verá a metade inferior do início de algo como:

du: cannot read directory '/some/directory': Permission denied

Resumindo, dunão foi possível ler todo o disco. Refaça o ducomo root, possivelmente com quaisquer outras alterações de segurança necessárias para permitir que ele veja tudo.

Se isso não explicar tudo, poste o que você obteve. Mas faça isso como texto, não como imagem, e inclua o comando inicial e quaisquer erros que surjam.

Você parece ter perdido 10G. Você pode tentar forçar um fsckno disco. Muitas distribuições modernas desabilitam-no completamente em sistemas de arquivos com diário, mas eu pessoalmente tenho visto muita corrupção mesmo com o diário para permitir que ele seja desabilitado.

Você precisa de:

1. um meio específico de distribuição para forçar o fsck, normalmente como parte de uma reinicialização.
2. para mudar para o modo de usuário único, de preferência antes de / ser montado para leitura/gravação, e faça isso fsck.
3. para inicializar a partir de outra mídia e fsck /dev/sda2 você mesmo.

Se houver muitos problemas, eu recomendaria usar o tune2fs para alterar os requisitos do fsck para o disco.

/varestá consumindo 8,7G. Confira /var/logs. Você pode usar ferramentas como o baobá para entender rapidamente o que está ocupando muito espaço.

Meu palpite é que o systemd grava logs com muita frequência. Experimente o seguinte:

sudo journalctl --rotate
sudo journalctl --vacuum-time=1s

Se o espaço liberar, SystemMaxUse=100Mdefina /etc/systemd/journald.conf.