Como faço para parar essa perda constante de espaço livre?

Eu estava executando o Ubuntu, como de costume, quando, de repente, recebi uma caixa de diálogo dizendo que só tinha 1,2 GB de espaço livre. Uma hora antes, eu tinha 30 GB de espaço livre.

Excluí algumas coisas e trouxe o espaço livre de até 25 GB. Mas continua a diminuir. Tentei remover arquivos de log antigos e truncar arquivos de log e tal, e continua a diminuir!

Tentei usar o Disk Analyzer para descobrir de onde vinha toda essa perda de espaço livre e não funcionou, pois mostrava tudo como deveria. Reiniciei e, eventualmente, o Ubuntu fez uma verificação de disco que, de alguma forma, trouxe o espaço livre de volta para 40 GB, mas ainda continua a diminuir cerca de 10 GB por dia. Continuo tentando encontrar novas maneiras de liberar espaço, mas é como um processo automatizado de diminuição do espaço em disco que não consigo parar.

Não sei o que fazer Como posso encontrar a causa e impedir que meu espaço livre diminua?

Aqui está a saída de sudo du -sh /var/* ~/.xsession-errors:

13M /var/backups
204M    /var/cache
112M    /var/crash
4.0K    /var/games
503M    /var/lib
4.0K    /var/local
0       /var/lock
9.5G    /var/log
85M     /var/mail
4.0K    /var/metrics
24K     /var/opt
0       /var/run
1.7M    /var/spool
391M    /var/tmp
11G     /var/tvmobili
20K     /var/www
224K    /home/school/.xsession-errors

Você tem alguns logs fora de controle. Em vez de excluir todos os dias como loucos, encontre o (s) arquivo (s) de crescimento rápido e procure dentro para investigar o que pode estar causando isso. Talvez algum programa esteja girando em um loop registrando alguma condição. Desative esse programa, desative seu log ou tente corrigir a condição da qual está reclamando.

Se um arquivo estiver crescendo diante de seus olhos e você não tiver idéia de qual programa está gravando nele, poderá descobrir isso facilmente. Aqui está um exemplo. Quem /var/log/syslogabriu? Nós usamos o fusercomando:

# fuser /var/log/syslog
/var/log/syslog:      602

Apenas um processo foi /var/log/syslogaberto. É o processo 602. O que é isso? Não vamos nos preocupar com pse grep, mas olhe /procdiretamente para o sistema de arquivos:

# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd

Ah, é sim rsyslogd. Não estamos surpresos que rsyslogdtenha /var/log/syslog/aberto.

Não é garantido que este método funcione. O motivo é que os programas não precisam manter os arquivos abertos para gravar neles. Suponha que você tenha um processo que abre um arquivo, anexa a ele e depois o fecha. Você terá uma investigação um pouco mais difícil. Você pode executar fuservárias vezes até que por acaso pegue o processo "em flagrante". Esse processo em si pode entrar e sair da existência rapidamente. Outro problema é que vários processos podem ter o arquivo aberto, mas apenas um está aumentando. Nesse caso, você pode rastrear as chamadas do sistema.

# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file:   1234 23459

Opa! Dois processos estão abertos: 1234 e 23459. Vamos ver o que eles estão fazendo:

# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}

Não está fazendo nada, apenas bloqueando uma selectchamada. Ctrl-C para interromper o rastreamento:

select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>

Confira o próximo:

# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C

Opa, esse alguém está escrevendo constantemente. Deve ser o ruim. Podemos até verificar se o descritor de arquivo 5 no qual o processo está gravando é de fato o arquivo grande:

# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr  3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file

Não suspeito que você tenha um sistema de arquivos corrompido, mas para forçar uma verificação completa, não é necessário inicializar um DVD.

Primeiro, revise a configuração de contagem máxima de montagens do seu sistema de arquivos. Identifique sua partição usando o comando df. Exemplo em um sistema Ubuntu que tenho aqui:

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda1       18062108 5499320  11645284  33% /
udev              392152       4    392148   1% /dev
tmpfs             159768     768    159000   1% /run
none                5120       0      5120   0% /run/lock
none              399416     200    399216   1% /run/shm
/dev/sr0           43668   43668         0 100% /media/VBOXADDITIONS_4.1.4_74291

Você pode ver que o /sistema de arquivos está montado /dev/sda1. O mesmo /dev/sda1ocorre com o dispositivo de armazenamento da partição raiz (e a única partição nesse sistema específico).

Vejamos alguns atributos desse sistema de arquivos. É seguro fazer isso mesmo que esteja montado. O comando vomita muita saída. Aqui está um trecho:

$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /
[ ... SNIP ... ]
Last mount time:          Fri Mar 29 17:45:18 2013
Last write time:          Tue Mar  5 09:08:03 2013
Mount count:              22
Maximum mount count:      22
[ ... SNIP ... ]

Ei, olhe, a contagem de montagem é igual à contagem máxima de montagem. Da próxima vez que reiniciar, haverá uma verificação do sistema de arquivos. O importante é que a contagem de montagens seja um valor positivo. Se o seu for zero, altere-o para um valor positivo como 22 usando tune2fs -c 22 /dev/whatever. Zero significa que uma verificação nunca é forçada, independentemente de quantas vezes a partição é montada. Sistemas raramente reinicializados devem ter valores baixos aqui. Um servidor que fica inativo uma vez por ano provavelmente poderia usar um fsck toda vez que reiniciar. Você também pode definir intervalos de verificação baseados em datas.

Agora, para forçar uma verificação, você pode substituir a contagem real para ser maior ou igual ao máximo e, em seguida, reiniciar. Isso é feito com o capital C: tune2fs -C 1234 /dev/whatever. Agora, a partição parece ter sido montada 1234 vezes sem uma verificação, que é maior que o máximo de um ou dois dígitos.

Uma verificação de disco liberou parte do espaço, sugerindo que esse problema (ou parte dele) pode estar relacionado à corrupção do sistema de arquivos. Se for esse o caso, você poderá liberar mais espaço examinando e reparando o sistema de arquivos. No entanto, se a corrupção está acontecendo perpetuamente (o que pode ou não ser o caso), isso geralmente significa que o disco rígido está morrendo. Se seus backups (de seus documentos e de outros arquivos importantes que seriam difíceis de substituir) não estão completamente atualizados, faça um backup de tudo o que é importante agora!

Para verificar e reparar o disco, ele não pode ser montado (pelo menos, não leitura / gravação). Portanto, você deve executar o utilitário de reparo em um ambiente ativo (CD / DVD ou USB ativo). Primeiro, você terá que descobrir o nome do dispositivo da partição que contém seus arquivos.

Portanto, no sistema instalado , execute:

mount | grep ' on / '

(Certifique-se de incluir o espaço entre o /e '.)

Você receberá algo como:

/dev/sda8 on / type ext4 (rw,errors=remount-ro)

O texto anterior on- no exemplo da minha máquina /dev/sda8- é o nome completo do dispositivo para sua partição raiz ( /). Escreva isso - você precisará.

Em seguida, inicialize o computador a partir de um CD / DVD ou unidade flash USB do desktop Ubuntu, como o que você usava para instalar o Ubuntu originalmente. (Se este for um sistema Wubi, instalado com o instalador do Windows, informe-nos. Não espero isso, considerando o que você relatou, mas se for esse o caso, o procedimento será diferente.)

Selecione Experimente o Ubuntu sem instalar (não instale o Ubuntu ). Quando você obtiver uma área de trabalho em funcionamento, pressione Ctrl+ Alt+ Tpara abrir uma janela do Terminal. Em seguida, execute este comando:

sudo e2fsck -fkccp /dev/sda8

Mas certifique-se de substituir /dev/sda8pelo nome completo do dispositivo certo para sua /partição, como você obteve através do método detalhado acima.

Isso pode demorar um pouco. As copções incluídas nesse comando fazem com que ele verifique a superfície do disco em busca de erros, bem como o sistema de arquivos (e marque as áreas ruins como ruins para que não sejam usadas). Você pode deixar de ccfora se quiser (se quiser, também pode deixar de fora k), mas recomendo mantê-los.

Você pode ser solicitado a corrigir certos problemas, se e2fsckachar que há uma probabilidade significativa de que tentar corrigi-los possa causar perda de dados. ( pIsso faz com que ele resolva todos os problemas que você acredita que podem resolver sem causar complicações.)

Eu recomendo que você esteja fortemente inclinado a permitir que ele conserte o que quiser, pois você só deve fazer isso depois de garantir que seus backups estejam atualizados . Se você deseja tentar correções potencialmente perigosas sem avisar, substitua ppor y.

Depois disso, reinicie o sistema Ubuntu e veja se há espaço livre. Caso contrário, ou se o problema persistir, comente e edite sua pergunta para fornecer detalhes.

esse problema foi resolvido, era o firewall que escrevia toneladas de logs e arquivos de codificação tvmobili