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.
sudo du -sh /var/* ~/.xsession-errorsfavor? (esses dois lugares que eu esperaria explodir se houver algo bobo). Caso contrário, estou com Eliah - isso é indicativo de problemas no disco. Leve isso a sério.