Meu / var / log / é misteriosamente preenchendo GBs em minutos! Alguma cura antes de eu reinstalar o Debian 7?

Question

Bom dia, companheiros entusiastas do * nix!

Eu tenho usado o Debian 7 por um tempo agora e depois de uma atualização recente eu notei que constantemente ficava correndo o espaço na minha partição raiz. Eu quero dizer até o ponto em que eu tinha '0' bytes no disco! Então, depois de um lote de busca, eu consegui zerar na pasta / var / log. Eu usei ls -s -S para organizar os arquivos por tamanho nessa pasta e notei que três arquivos tinham tamanho GB (como 13-15 GB):

• syslog
• mensagens
• kern.log

E sim, logrotate está funcionando bem. Está girando os logs. Por exemplo, eu vejo kern.log.1 etc em / var / log. O problema é que os logs estão se enchendo tão rápido que não há nada que o logrotate possa fazer.

Aparentemente, alguns processos de log no sistema operacional estão gravando muitos dados que podem ser causados por erros constantes ou algo assim (??). Eu não sei. Tudo o que sei é que meu laptop está superaquecendo, simplesmente porque há muito processamento acontecendo o tempo todo devido a esse processo de gravação constante. Então, estou perdendo o poder da CPU E o espaço em disco.

Minha pergunta é: como posso determinar qual processo / daemon está criando esse problema? Como obtenho a raiz do problema para poder corrigi-lo? Ler esses arquivos de log ENORMES não é uma opção. Por favor. Se eu tentar abrir um arquivo de log de 15 GB em um editor de texto, como o leafpad ou o bloco de notas, em um laptop já ocupado, bastam eras e idades para abrir . Isso não é prático.

Eu percebo que esta questão é ampla porque pode haver qualquer processo / daemon causando isso, mas eu quero saber se alguém já experimentou isso antes, e se há algum suspeito que eu possa ver.

ATUALIZAÇÃO:

Seguindo o conselho de Eric, organizei os arquivos em / var / log por hora de modificação e 'syslog' foi o último. Então, eu usei tail . O resultado:

Apr 10 00:53:37 MyMachine kernel: [11608.690733]  [<ffffffffa08e4005>] ? ath9k_reg_rmw+0x35/0x70 [ath9k_htc]
Apr 10 00:53:37 MyMachine kernel: [11608.690742]  [<ffffffff81084f57>] ? process_one_work+0x147/0x3b0
Apr 10 00:53:37 MyMachine kernel: [11608.690750]  [<ffffffff81085764>] ? worker_thread+0x114/0x480
Apr 10 00:53:37 MyMachine kernel: [11608.690756]  [<ffffffff81556065>] ? __schedule+0x2e5/0x790
Apr 10 00:53:37 MyMachine kernel: [11608.690765]  [<ffffffff81085650>] ? create_worker+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690772]  [<ffffffff8108ae91>] ? kthread+0xc1/0xe0
Apr 10 00:53:37 MyMachine kernel: [11608.690780]  [<ffffffff8108add0>] ? kthread_create_on_node+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690788]  [<ffffffff8155a23c>] ? ret_from_fork+0x7c/0xb0
Apr 10 00:53:37 MyMachine kernel: [11608.690795]  [<ffffffff8108add0>] ? kthread_create_on_node+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690800] ---[ end trace 12dc8d8439345c1d ]

Infelizmente, isso não me dá muita dica.

    

Answer 1

Na verdade, há uma strong dica no fragmento syslog que você postou. O fim da linha

Apr 10 00:53:37 MyMachine kernel: [11608.690733]  [<ffffffffa08e4005>] ? ath9k_reg_rmw+0x35/0x70 [ath9k_htc]

mostra que o rastreamento de pilha é devido a um erro inesperado em um driver de dispositivo chamado ath9k_htc . Esperançosamente, o kernel não entrou em pânico, mas a repetição contínua de erros está preenchendo seu sistema de arquivos.

Em seguida, colocaria blacklist no driver ath9k_htc wifi usando este comando e reinicializando:

echo "blacklist ath9k_htc" | sudo tee -a /etc/modprobe.d/blacklist.conf

Entretanto, cuidado ao evitar que o wifi funcione se o driver ath9k_htc for usado e funcional apesar dos erros.

Você pode verificar se um dispositivo wifi esperado pelo driver ath9k_htc está presente em sua máquina executando lsusb e ver se um dispositivo corresponde a uma lista disponível aqui: link

    

Answer 2

Você não precisa abrir os arquivos de log em um editor para ver o que os está inundando. Basta olhar para as últimas linhas:

tail -n 999 /var/log/syslog | less

Arquivos de log de um processo sempre contêm o ID do processo:

Apr 10 00:00:01 harfang /USR/SBIN/CRON[345]: (root) CMD ( /usr/local/bin/midnight-stuff )
Apr 10 00:00:01 darkstar wibbled[1234]: I'm bored
Apr 10 00:00:01 darkstar wibbled[1234]: I'm still bored
Apr 10 00:00:01 darkstar wibbled[1234]: I'm bored
Apr 10 00:00:02 darkstar wibbled[1234]: I'm still bored
Apr 10 00:00:02 darkstar wibbled[1234]: I'm bored

Isso informa que o processo 1234, que é uma instância do daemon wibbled , está produzindo muitas mensagens de log. Você pode querer matá-lo e verificar sua configuração.

Se kern.log está crescendo muito, seus logs não estão vindo de um processo, mas do kernel. A inundação nos logs do kernel é mais rara e pode ser mais difícil de definir. Pode ser devido a um processo que está sendo reaparecido em um loop apertado e está travando imediatamente (talvez devido à pouca memória no sistema). Também pode ser devido a um driver com bugs. Você precisa ver as mensagens para entender a causa.

No seu caso, você está vendo um backtrace de um driver. O driver está encontrando um erro não fatal incessantemente. Tente descarregar:

rmmod ath9k

(Por que ath9k ? Porque esse é o driver que fornece a função ath9k_reg_rmw , mas na verdade porque o nome do módulo seria mencionado algumas linhas mais acima do bit que você incluiu na sua pergunta.) Se o driver não for t em um módulo ou não pode ser descarregado, procure outra maneira de desabilitá-lo ou parar de acionar seu bug; como fazer isso depende do driver e do que está errado.