Quem está preenchendo meu disco?

Question

Eu tenho meu disco principal totalmente preenchido:

root@kodi:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           385M   12M  374M   3% /run
/dev/sda1        88G   84G     0 100% /
tmpfs           1.9G  4.0K  1.9G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sdb1       917G  429G  442G  50% /media/Cloud
/dev/sdd1       917G  813G   58G  94% /media/Tera
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           385M     0  385M   0% /run/user/1000
root@kodi:/#

/ dev / sda1 é o meu disco principal onde o ubuntu está instalado:

root@kodi:/home/fmf# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=9fab4895-7ccb-4415-b26d-311a17036cda       /               ext4    errors=remount-ro 0       1

# swap was on /dev/sda5 during installation
UUID=7b158f58-e4c1-4717-aa5f-dbeaa79ab93c       none            swap    sw              0       0

UUID=f9079f52-7661-48ad-9bc4-0d2452be66af       /media/Tera     ext2    defaults,nofail 0       0
UUID=fb1f92ee-54f5-44f8-ba92-544e90e6dfeb       /media/Cloud    ext2    defaults,nofail 0       0

root@kodi:/home/fmf#

Fiz algumas pesquisas no google e encontrei alguns comandos para testar quem é o responsável, mas não consigo descobrir quem está preenchendo:

root@kodi:/# du --exclude=/media -cksh * | sort -hr | head -n 15
du: cannot access 'proc/16360/task/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/task/16360/fdinfo/3': No such file or directory
du: cannot access 'proc/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/fdinfo/3': No such file or directory
1.3T    total
1.3T    media
3.5G    home
3.0G    usr
1010M   var
645M    root
630M    lib
99M     boot
17M     bin
15M     sbin
13M     etc
12M     run
196K    tmp
16K     lost+found
12K     srv
root@kodi:/#

Aparentemente, não há nenhum arquivo ou diretório tão grande para preencher o 84G do meu disco.

Alguns dias atrás, descobri que o disco estava cheio devido a erros de xsession que enlouqueceram. Eu encontrei este é um bug conhecido no Ubuntu e resolvi criar uma linha crontab que a cada dez minutos excluir erros .xsession-erros. Na verdade, agora eu não tenho mais isso no meu diretório pessoal.

Qualquer ajuda, por favor?

    

Answer 1

O problema com o seu cronjob é que .xsession_errors provavelmente ainda está aberto por alguns aplicativos ou serviços do sistema e é por isso que ele será escondido da tabela do sistema de arquivos quando excluído, mas ainda está no disco e erros serão gravados para isso.
Então, vai encher o disco, mas agora você não pode mais vê-lo.

O @rinzwind visa exatamente esse comportamento quando ele (corretamente) sugere remover o cronjob e procurar os erros. Esta é a única maneira de corrigir o problema corretamente.

Como solução alternativa, você pode truncar o arquivo .xsession_errors com um cronjob assim:

17 */2 * * *  truncate -cs 0 path/to/.xsession_errors

Mas antes de fazer isso, você REALMENTE deve tentar corrigir os problemas subjacentes que criam essas mensagens de erro em .xsession_errors

    

Answer 2

  

Quem está preenchendo meu disco?

desde que você faça isso ...

  

Eu descobri que este é um bug conhecido no Ubuntu e resolvi criar uma linha crontab que a cada dez minutos exclui .xsession-errors

é impossível responder a essa pergunta.

Por favor, siga as instruções abaixo para obter os erros que precisamos ver:

• Remova a linha crontab que você adicionou e remove .xsessions_errors .
• Reinicialize e verifique na linha de comando o que está preenchendo .xsessions_errors usando tail -f 100 ~/.xsessions_errors .
• Quando você encontrar algum problema que seja repetido, copie alguns deles na sua pergunta.
• Adicione a linha crontab de volta para poder usar seu sistema.
• Aguarde a correção do problema e aplique-o. Em seguida, remova a linha crontab novamente (a exclusão do arquivo .xsessions_errors sempre deve ser evitada).

Answer 3

Quando há grandes diferenças (digamos, mais do que alguns por cento) entre (como root) df -g /some/partition_root e du -gx /some/partition_root ( -x diz ao du para se limitar à mesma partição, é útil verificar '/' por exemplo): provavelmente ainda há arquivos abertos que alguns processos ainda estão gravando, mas que você excluiu no disco (portanto: o arquivo ainda existe desde que seja aberto pelos processos e preenche o espaço em disco) (df -g vê isso) mas como não há mais links (ou nomes de arquivos) para seus inodes, du-gx os perde.

No seu caso, compare as saídas de:

df -g /
du -gx /

Para descobrir quais são os arquivos com menos de 1 links (ou seja, arquivos excluídos, mas ainda abertos):

lsof -nP +L1  /

Verifique os nomes dos processos e os pids para ver quais são os processos que estão sendo gravados nesses arquivos "fantasmas" e aja de acordo (alguns deles podem ser interrompidos / iniciados e, quando forem interrompidos, o arquivo será liberado e espaço liberado, outros podem necessitar de uma reinicialização adequada)